Delivery operations information system with planning and scheduling feature and methods of use

ABSTRACT

The present invention provides a system for managing information related to a delivery service provider and systems of using such a system. The system and systems provided herein allow a delivery service provider to coordinate with efficiency the volume of mail or packages to be delivered with the carrier resources available to deliver them. In accordance with one aspect of the invention, the delivery operation information system tracks quantities of articles, schedules their distribution, and schedules and tracks the work force that distributes the articles.

PRIORITY

Under provisions of 35 U.S.C. §119(e), this Application claims thebenefit of U.S. Provisional Application No. 60/602,592, filed Aug. 19,2004, and U.S. Provisional Application No. 60/706,510, filed Aug. 8,2005, both of which are entitled “Delivery Operations InformationSystem,” and both of which are incorporated herein in their entirety byreference.

DESCRIPTION OF THE INVENTION

1. Field of the Invention

The present invention generally relates to the field of trackingquantities of mail for delivery, monitoring their distribution, andscheduling and tracking the work force that distributes the mail. Moreparticularly, the invention relates to a system and method for trackingmail volumes and distribution, and tracking and scheduling a mailcarrier work force.

2. Background of the Invention

The United States Postal Service (USPS™) is an independent establishmentof the United States government that provides mail delivery and otherservices to the public. The USPS™ is widely recognized as a safe andreliable means for sending and receiving mail and other items. With theadvent and steady growth of electronic commerce, the physical mailstream will increasingly be utilized for sending and receiving packagesand other items. Accordingly, providers of delivery service such as theUSPS™ will continue to require better systems and methods to meet theincreasing demand for faster, more efficient and reliable delivery ofmail and other deliverable packages.

Currently, the USPS™ has the enormous task of assigning, and optimizing,delivery routes for hundreds of thousands of mail carriers who dailydeliver approximately 617 million pieces of mail to about 141 milliondelivery points throughout the nation. The previous delivery operationssystem was challenged by inefficiencies, outdated technology, andcompliance with federal mandates and unionized labor rules. For example,some carriers were obligated to work overtime in order to complete theirassigned delivery routes, while others were paid for a full eight-hourshift although they could finish their delivery routes in less thaneight hours, with time to spare.

A study of existing delivery operations systems used by the USPS™identified several deficiencies: the existing system was DOS-based,making it difficult for a supervisor to interface with the necessaryapplications to properly perform the job; disparate legacy systems fromthe 1980's were redundant and could not effectively communicate; andsupervisors and route examiners did not use the same system and so couldnot effectively share information.

Thus, new methods are needed to maximize on-time and profitable deliveryof the mail while complying with federally required mandates and laborcontract rules. There is a need for a delivery operation informationsystem that allows a mail carrier supervisor to access, analyze, and acton data in near real time so that the supervisor can make sound businessdecisions on what needs to be done for that day. In addition, there is aneed for a system that provides a supervisor with the ability to analyzeoperations to identify and address issues in his or her delivery unit,or with individual routes or individual carriers. There is also a needfor a system that allows for long-range planning, such as for example aweek, a month, or a year, and for a system that allows for a streamlinedroute inspection and adjustment process to provide current update ofcritical information to the route assignment process.

SUMMARY OF THE INVENTION

The present invention provides a system for managing information relatedto a delivery service provider such as the USPS™ and methods of usingsuch a system. The system and methods provided herein allow a deliveryservice provider to coordinate with efficiency the volume of mail orpackages to be delivered with the carrier resources available to deliverthem. In accordance with one aspect of the invention, the deliveryoperation information system tracks quantities of articles, schedulestheir distribution, and schedules and tracks the work force thatdistributes the articles. These articles can include, but are notlimited to, mail such as letters, flat mail, bulk mail, parcels, andother packages. The terms articles, mail and packages are usedinterchangeably throughout the specification. It is understood that suchterms are intended to include any item that is deliverable by air orsurface transportation.

In accordance with an exemplary embodiment of the invention, a method isprovided for managing delivery of articles to locations along routesover a plurality of days. The method can comprise the steps ofdeveloping a first database that identifies routes for delivery of thearticles, and developing a second database that identifies regularlyscheduled carriers. Carriers can be assigned to the routes in responseto the data from the first and second databases. The method furtherprovides display screens selectively showing the carriers assigned tothe routes and showing the number of hours projected for those carriersto complete those routes over the plurality of days. A third databasethat identifies the assignments and projected hours can be developed,along with a fourth database that identifies budgeted work hours for thecarriers. Display screens can be provided for selectively showing datafrom the third and fourth databases in a form that permits comparison ofthe hours projected and hours budgeted for the delivery of the articlesalong the routes over the plurality of days.

In accordance with another exemplary embodiment of the invention, asystem is provided for managing delivery of articles to locations alongroutes over a plurality of days. The system can comprise a firstdatabase that identifies routes for delivery of the articles, and asecond database that identifies regularly scheduled carriers. The systemcan further comprise a component for assigning carriers to the routes inresponse to the data from the first and second databases, and a displayscreen for selectively showing the carriers assigned to the routes andshowing the number of hours projected for those carriers to completethose routes over the plurality of days. A third database thatidentifies the assignments and projected hours, and a fourth databasethat identifies budgeted work hours for the carriers can also beprovided. The system can also comprise a display screen for selectivelyshowing data from the third and fourth databases in a form that permitscomparison of the hours projected and hours budgeted for the delivery ofthe articles along the routes over the plurality of days.

Additional objects and advantages of the invention will be set forth inpart in the description which follows, and in part will be obvious fromthe description, or may be learned by practice of the invention. Theobjects and advantages of the invention will be realized and attained bymeans of the elements and combinations particularly pointed out in theappended claims.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate embodiments of the invention andtogether with the description, serve to explain the principles of theinvention.

FIG. 1 illustrates a diagram of an exemplary embodiment of a deliveryoperations information system of the present invention.

FIG. 2 illustrates a diagram of particular subcomponents of a deliveryoperations information system of the present invention.

FIG. 3 illustrates a diagram of an exemplary embodiment of a dailymanagement workload system of the present invention.

FIG. 4 illustrates a diagram of an exemplary embodiment of a performancereports system of the present invention.

FIG. 5 illustrates a diagram of an exemplary embodiment of a planningand scheduling system of the present invention.

FIG. 6 illustrates a diagram of an exemplary embodiment of a route andunit maintenance system of the present invention.

FIG. 7 illustrates a diagram of an exemplary embodiment of a managedservice points and street management system of the present invention.

FIG. 8 illustrates a diagram of an exemplary embodiment of a routeadjustment system of the present invention.

FIGS. 9-166 illustrate a series of screen shots from exemplaryembodiments of the present system.

DETAILED DESCRIPTION

The present invention provides a delivery operations information systemfor a delivery service provider such as the USPS™ and methods of usingsuch a system. The delivery operations information system (DOIS) andmethods provided herein allow a delivery service provider to coordinatewith efficiency the volume of mail or packages to be delivered with thecarrier resources available to deliver them. For example, DOIS can allowa postal supervisor to glance at a computer screen and see a quickvisual snapshot of information, such as for example daily mail volumefor individual mail routes, carrier shift schedules, whether a carrierwill have spare time in his shift due to the day's mail volume, whichcarriers have the day off, and which carrier has requested overtime.Based on this information, the system can provide an accurate andreliable automated method for matching up mail loads with availablecarriers. Accordingly, DOIS can serve as a high-tech matchmakingservice, using data to match up workload with available carriers ratherthan guesswork. By managing capacity and demand, use of DOIS can resultin improved resource allocation, lower labor costs, and improvedreliability and higher quality mail service.

The delivery operations information system of the present inventioncomprises a software application that combines client/server technologywith highly integrated applications, including one or more softwarecomponents, a central repository, a graphical user interface, and astandard platform that can scale with changing demands. The mainframeback-end captures large amounts of information about mail volume,delivery routes and inspections, carrier schedules, time and attendance,and budget. DOIS provides a software application that feeds data frommultiple sources into the central repository, so that users of thesystem such as managers or supervisors can quickly view critical data,such as for example the amount of mail scheduled to arrive at afacility, and adjust carrier workloads to meet the demand.

FIG. 1 illustrates an exemplary embodiment of a delivery operationsinformation system (DOIS) 100 of the present invention. The DOISapplication 110 may run on a delivery unit computer or workstation 112as shown, which can be connected to a network 120 for sharing data witha mainframe 130. The network can be a local area network (LAN) or a widearea network (WAN), such as for example a Postal Routed Network (PRN) ora Managed Network Services (MNS) of the USPS™. The mainframe 130 can beused to store data and can communicate with a web-based server 140, suchas for example Web Enterprise Information System (WebEIS) of the USPS™,that can be run from a manager's computer 142. The mainframe 130 cancommunicate either directly with the web-based server 140 or through thenetwork 120. Data may be collected and transferred between the DOISapplication 110 and a data collection device (DCD) 150, as shown.Further, the network 120 may also interact with one or more databaseinterfaces 160. Exemplary databases useful for interfacing with thepresent system include, for example, Address Management System (AMS),National Budget System (NBS), Time and Attendance Collection System(TACS), and Web End of Run (WebEOR) of the USPS™. It is understood, ofcourse, that FIG. 1 merely illustrates an example of the technicalarchitecture of the present invention.

In one embodiment of the invention, the delivery operation informationsystem 100 can be a client-server software application, with data beingstored on one or more of a client or a mainframe. The client(s) andmainframe(s) of the system can be connected via a local area network ora wide area network, as previously described. It is understood, ofcourse, that data may be transferred in both directions. For example, adatabase of route records may be maintained on the mainframe 130, and aworkstation user can transfer route data between the mainframe 130 andthe workstation 112.

The client can be, in one embodiment, a Windows-based PC or laptop andfurther can be located in the delivery unit. A user may have his own PC,or a number of users may share a PC. As illustrated in FIG. 1, the PCcan receive data from the data collection device 150 either via awireless connection or a physical connection. The PC in one embodimentcan have about 128 mB of RAM. The mainframe 130 can be in one embodimentIBM or Amdahyls (e.g., AMDHL 2000 Model 2128E, and AMDHL 2000 Model2158E). A middleware, for example Shadow (NEON Systems Inc.), may run onthe mainframe 130, allowing the mainframe 130 to act as a server. It isto be understood that this description of the architecture of the systemis exemplary. Those skilled in the art would understand that othersuitable architectures could also be used, such as servers replacing theNEON middleware product.

A separate version of a DOIS application 110 may be provided by thepresent invention for use with a laptop computer. The laptop version mayinclude many of the same features, but is not as comprehensive. Certainfunctions, therefore, may be left out of the laptop version.

The system 100 described herein, in one embodiment, can allowconnectivity to other applications, such as for example Form Flowsoftware or Microsoft Excel. In another embodiment, the system can allowconnectivity to other databases, such as for example legacy postalservice databases. Further, it is understood that the present softwareapplication can work with utilities other than those already mentioned,and that the DOIS software application may include one or moreadditional software components for implementing the following managementfunctions.

As illustrated in FIG. 1, the system 100 may also allow connectivity toa data collection device (DCD) 150, and may, in one embodiment, provideinstructions as to how to configure the DCD for different functions suchas, for example, a route inspection, mail volume recording, or streetmanagement. A DCD may be used, for example, in counting mail, trackingmail, and tracking the movements of carriers.

In one aspect of the embodiment, DOIS can comprise a web page that canbe viewed online and allow users to view the system status. For example,the web page may inform the user of the system's availability, andwhether the system is fully functional, slow, or unavailable. This canbe achieved, for example, by tracking the length of time it takes forDOIS to return a communication sent from the web page. The system'savailability may be indicated, for example, by an easily viewable symbolsuch as a traffic light having a signal that is green when the system isfully functional, yellow when the system is slow, and red when thesystem is unavailable. The system status can be updated by refreshingthe web page.

In another aspect, the DOIS website can provide additional onlinesupport for the user, such as for example a “Tip of the Day,” or theability to reset system passwords or view certain information online. Inyet another aspect, each of the system's windows can include a helpbutton. The help button is window-sensitive and includes extensiveonline help, including a brief description of the purpose of the window.

Turning now to methods for using DOIS, a user of the delivery operationsinformation system may be, for example, a mail carrier (“carrier”), adelivery unit supervisor, a system administrator, a district, area ornational manager. Each user can be assigned a profile and a uniqueidentifier or username, and must log on with a password, which may bechanged, to the secure system of the present invention in order to gainaccess to the delivery operations information system 100. In anexemplary embodiment, only authorized users may access the system 100.The system 100 may recognize and allow access, for example, only tothose users whose profiles have been stored in the system.

In one embodiment, a user may only have access to limited informationand/or operations of the system 100. For example, a delivery unitsupervisor may assign a carrier to a delivery route in his or herdistrict, or may modify a delivery route in that district, but may notassign a carrier to a delivery route outside that district or modify adelivery route outside that district. In some embodiments, only a localor district manager may modify a delivery route in any particulardistrict. Thus, the system 100 may be configured to allow selectiveusers access to some, but not all of the functions of the system 100.

With the system 100 of the present invention, a system administrator oranother authorized user may maintain user profiles, districtorganizations, and 52-day implementation plans (i.e., calendars ofevents that must take place in order to meet contractual requirements).For example, a user may add an activity to a 52-day plan. A systemadministrator or other authorized user may view the profiles of otherusers, including, for a given ID and user name, the user's primarydelivery unit and class (e.g., supervisor, manager, systemadministrator, etc.). The system administrator or other authorized usermay also create a new profile for a user or a new user class (e.g.,supervisor, manager, route inspector, etc.) and the delivery unit forthat particular user class.

A system administrator or another authorized user may further use theDOIS 100 to view a district organization as a tree format, edit,reassign, delete, and/or add to the district, its facilities, and itsmanagement areas. A system administrator or other authorized user mayalso add a new post office operation area or a new installation (e.g.,an individual building or multiple facilities), and may assign a financenumber, city, and state to the new installation. A system administratoror other authorized user may also add a new delivery unit. A systemadministrator or other authorized user may also assign an existing ZIPcode™ to that district.

As shown in FIG. 2, the delivery operations information system 100 ofthe present invention comprises two basic operational units: officemanagement 200 and street management 400. Office management 200 caninclude several functions such as a daily workload management system300, a performance reports system 320, a planning and scheduling system340, a route and unit maintenance system 360, and a managed servicepoints and street management system 380. Street operations 400 caninclude functions such as a route adjustment system 500.

In general, DOIS can include a database comprising information regardingindividual carriers, delivery units, routes, and mail volumes. Anindividual user of DOIS, or of the daily workload management system,performance reports system, planning and scheduling system, route andunit maintenance system, managed service points and street managementsystem, or route adjustment system, may have access to some or all ofthis information.

For each carrier the DOIS database can include the carrier's status(e.g., regular carrier, part-time carrier, transitional employee (TE)carrier, casual carrier, utility carrier, or substitute carrier), thecarrier's assigned route (or whether the carrier is currentlyunassigned) and the date the carrier was assigned to that route, thehours worked to date by that carrier and whether the carrier is on anovertime desired list (OTDL), the carrier's delivery unit, and thecarrier's prior performance reports. The database can also provide foreach carrier the number of days the carrier has physically worked on aparticular route, the last day the carrier worked a particular route,the days the carrier worked on a particular route in the office, and thelast day the carrier worked on a particular route on the street.

The overtime desired list can comprise a list of carriers desiringovertime. In one embodiment, the OTDL can include the identities of thecarriers on the list, as well as a record of overtime offered to eachcarrier on the OTDL, overtime worked by each carrier on the OTDL, andovertime refused by each carrier on the OTDL, including any reasons forrefusal of overtime.

For each route, the DOIS database can include information, such as forexample the route (e.g., the path traveled, and whether the route is afull or auxiliary route), the overall time for the route (and whetherthe route is over or under eight hours on a given day, based on thecalculated workload), the travel time for the route, the route type(e.g., combination, collection, or relay), the route environment (e.g.,residential, business, or mixed), the type of delivery (e.g., foot,dismount, curb line motorized, park and loop, etc.), the clock rings(e.g., reporting time, leave time, return time, end time), previousinspections (e.g., date(s) of previous inspections, findings of previousinspections), the projected mail volume for one or more delivery timesper day (e.g., a morning delivery and an afternoon or evening delivery),whether mail is delivered to that route on particular days (e.g.,weekends, Saturdays, Sundays, holidays), the fixed office time for theroute, the managed service points for the route, the non-delivery pointsfor the route (e.g., park points, relay points, collection boxes), andthe carrier assigned to the route.

For each delivery unit, the DOIS database can include information, suchas for example the carriers assigned to the delivery unit, the routesserviced by the delivery unit, and the supervisor of the delivery unit.

DOIS can also include information such as the projected or actual mailvolume, optionally by route, for a particular day, week, month, or year.It is understood that the term mail may include, for example, letters,magazines, postcards, or parcels, and may be shipped by, for example,air or surface. Mail volume may be measured by individual pieces or inlinear measurements. For instance, mail volume data may be collected byscanning individual pieces of mail and maintaining a count of thepieces. Alternately, stacked mail may be measured using a ruler oryardstick. With DOIS, a user may view the mail volume by category suchas, for example, first class letter mail, first class flat mail,parcels, etc, and may view running totals.

DOIS can also provide advance notice of the amount of mail a sortingfacility will be sending to a delivery unit. This advance notice wouldallow the delivery unit to plan ahead for incoming mail volume. Insituations where mail is received by individual offices such as forexample post offices or courier offices, from a central sortingfacility, a user may record the amount of mail that comes in for eachdelivery from the sorting facility, and the time of the delivery so asto track inflow of mail. In one embodiment, a user may modify a mailvolume value from a projected mail volume value to a measured mailvolume value after mail is received from a central sorting facility. Thesystem 100, in one embodiment, can allow a user to capture mail volumesmanually or by uploading data stored in a DCD 150. For example, acarrier may use a DCD 150 to enter the mail volume by route as he or shecounts the amount of mail to be delivered for that route for that day.

DOIS can further provide a list of route vacancies, which occur when aroute is not covered by an individual carrier, including plannedvacancies and vacancies that occur on a particular day as a result of acall-in (i.e., a carrier announces an unscheduled absence). A DOIS usermay create a vacancy by documenting a carrier's leave request, and mayrecord whether the leave is, for example, sick leave or annual leave,and whether a full or partial day of leave is requested. For a partialday, the user may further record the number of hours of leave taken. Theuser may also identify a date range for a carrier's multi-day leave. Inone embodiment, the system may print an appropriate leave formautomatically upon saving vacancy information.

While in DOIS, a user may change the information retrieved from onedelivery unit to another, or one delivery facility to another, withoutlogging out of the system. DOIS can also serve as a message broadcastingsystem. For instance, a national manager may be able to place a messageonto the system so that users will receive a notification on the screenafter logging into the system. In one embodiment, DOIS can provideonline forms for work-related accidents, or include applications formail holding and parcel redelivery.

DOIS can provide a method for managing delivery of articles bydeveloping a first database that identifies routes for delivery ofarticles, developing a second database that identifies the volume ofarticles to be delivered along each route, developing a third databasethat identifies the total estimated work time for completing anyidentified routes, developing a fourth database that identifies carriersassigned and assignable to all or portions of the routes, and theavailability of the carriers, and providing display screens selectivelyshowing the data from the first, second, third, and fourth databases topermit assignment of the carrier to the routes.

Also provided is a system for managing delivery of articles comprising afirst database that identifies routes for delivery of articles, a seconddatabase that identifies the volume of articles to be delivered alongeach route, a third database that identifies the total estimated worktime for completing any identified routes and a fourth database thatidentifies carriers assigned and assignable to all or portions of theroutes, and the availability of the carriers. The system also includes adisplay screen for selectively showing data from the first, second,third, and fourth databases to permit assignment of the carrier to theroutes.

As described, DOIS can provide a user with the ability to view multipledisplay screens or windows at the same time, so that a user can analyzedata from different information databases to formulate a businessdecision. For example, as shown in FIG. 147, a user can view a WorkloadStatus window alongside a Capture Mail Volume—AM Window to determinewhich carriers do not have a full day's worth of work based on the mailvolume for that route to which the carrier is assigned. The user canalso view the availability of the carrier, and from this informationassign carriers to routes, or portions of routes, balancing theassignments in order to meet the mail volume demand and satisfy the workcapacity of the carriers. For instance, a user can assign a route orsegment of a route to a carrier who is in proximity to that route orsegment, in order to help balance out the workload.

Particular features of the office management 200 and street management300 functions of DOIS are discussed in greater detail below.

Daily Workload Management System

As shown in FIG. 2, the delivery operations information system 100 ofthe present invention can include two main functional components: anoffice management module 200 and a street management module 400. Withinthe office management module 200, a daily workload management system 300can be provided. As depicted in FIG. 3, the daily workload managementsystem 300 can provide a mechanism for coordinating mail volume 302 witha carrier work force 308. In general, the mail volume 302 can comprisedata for projected mail volume 304 as well as actual mail volume 306.Factors such as, for example, a carrier's expected work schedule 310,expected and unexpected absences 312, and number of carriers requestingovertime 314 may be included in assessing the available carrier workforce 308.

In an exemplary embodiment, the daily workload management system 300 canallow a user to view, enter, or modify one or more carriers, deliveryunits, routes, and absences for a particular date. A user may also view,enter, or modify the projected or actual mail volume for a particulardate. This date may be the current date, the previous day, the followingday or, for example, any day of the following week, month, or year.

With the daily workload management system 300, a user may also adjust acarrier's start or end time in the event of, for example, a supervisor'sservice or safety talk with the carrier. For example, if a supervisorspends twenty minutes giving a talk, the carrier's route time may beadjusted by twenty minutes. In one embodiment, a user may adjust acarrier's route time in the event of a deviation from a planned routedue to, for example, construction along that route. A user may alsoadjust a carrier's schedule if that carrier starts earlier or later thanplanned. In one embodiment, a user may input time added to a carrier'soriginal route when the carrier is providing assistance to anotherroute. Thus, a user may change a carriers' begin time for a given day,as well as a carrier's regular scheduled start time.

The daily workload management system 300 may also allow a user to view,enter, or modify the projected or actual mail volume for a particularroute. The mail volume for a particular route may be projected based onhistorical data (e.g., mail volumes recorded the previous day, week,month, or year, or, for example, an average of the mail volume recordedfor that day in, for example, the previous years).

A user may also use the daily workload management system 300 to compareactual mail volume to projected mail volume, or mail volume from aprevious historical period such as the same period last year (SPLY). TheSPLY function of the daily workload management system 300 can permit theuser to assess the effect of anomalies, such as those due to weatherconditions (e.g., a heavy snowstorm) or unusual traffic congestion, andto plan the workload for the future. In one aspect of the system 300, auser may “roll in” undelivered mail from an earlier period, such as forexample the previous day or earlier in the same day. In another aspectof the system 300, a user may record a special event, such as forexample a heavy snow storm, so that other users viewing data for thatday at a later time will be alerted to the special event.

The system 300 can also provide a list of route vacancies, which occurwhen a route is not covered by an individual carrier, including plannedvacancies and vacancies that occur on a particular day as a result of acall-in. A user may use the daily workload management system 300 tomanage workload by, for example, creating a vacancy by documenting acarrier's leave request. A user may also choose a carrier's name, forexample, using a drop-down list, and then create a vacancy type such assick leave or annual leave. In some embodiments a user may indicatewhether the carrier is taking a full or partial day of leave and, for apartial day, may further record the number of hours of leave taken. Auser may also identify a date range for a carrier's multi-day leave. Insome embodiments, the system 300 may print an appropriate leave formautomatically upon saving vacancy information.

A user may then use the daily workload management system 300 to assignassistance from scheduled and unscheduled carriers. For example, a usermay specify the duration of the assistance, as well as whether theassistance will apply to an entire route or only to a portion of theroute. A user may request assistance from an unscheduled carrier if suchassistance is needed, for example, to cover a full route. A user canalso view the total overtime and under time for the total of thedelivery unit's routes, and can reassign workload so that the totalovertime and total under time equal, or approach, zero.

In one embodiment, a user may view a summary of a particular carrier'sassignment for the day, including the route the carrier is assigned to,and the carrier's expected total work time for the daily assignment. Thedaily workload management system 300 may also allow a user to generate areport of a carrier's performance, including, for example, work hoursover a period of time, and any difference from the hours expected.

With the daily workload management system 300, a user may also generatea workload status report which may provide information for one, some, orall of the routes and assignments made for a given day. The report mayinclude the identity of the route, the name of the carrier, the statusof the carrier, the type of carrier, the demonstrated performance of thecarrier, the volume the carrier has for the day, projections based onthe carrier's workload, the carrier's leave time, projections of thecarrier's return time, and projections of the carrier's total time forthe day. The report may also identify deviations from expected data, andmay provide a comparison to historical values.

The daily workload management system 300 also can allow a user to viewand/or edit details of regular and city routes, including, for example,the base route information, including office time, street time, how manydeliveries the carrier has, the carrier's begin time, leave time, andreturn time. These routes may be, for example, combination routes,collection routes, and relay routes. The user may also divide a route upinto smaller segments (e.g., by time or distance) that can be given toother carriers for delivery. The user may view or modify deliveryinstructions, or a form specifying delivery instructions, as describedabove.

A user may also produce a report displaying the carrier's revised routewith the daily workload management system 300. Such a report may beprinted either by carrier or by route for a given date. It is understoodthat the report may be printed with or without route times.

With the daily workload management system 300 of the present invention,a user may elect to “pivot” a route by reassigning a portion of thatroute. In some embodiments, the system 300 can allow the user to pivotby section (a given street or portion thereof on the route) or duration(the time to deliver the section). The system may also allow the user topivot the route by business deliveries or residential deliveries.

In some embodiments, the user may choose a pivot option, for example, bysection, and then select a number of sections (e.g., one, two, ten, ortwenty sections). Alternatively the user may pivot by duration (e.g.,one-hour, two-hour, or three-hour increments). In one embodiment, thesystem 300 may break down the route being pivoted into every delivery,and the mode and method of delivery for all the streets can be brokendown into individual sections or logical groups. The system 300 can givethe user start and end times, and determine how long it takes to delivereach logical group, the type of delivery (e.g., business orresidential), and the delivery method (e.g., mounted or park and loop).

The user may also be able to fill out reports and/or forms with thedaily workload management system 300. In one embodiment, a report and/orform may be generated which lists key information about a given routeincluding, for example, the carrier assigned, the replacement carrier,relay points, the number of deliveries on each relay point, park points,where the carrier goes to lunch, and how the carrier travels back andforth to lunch. In another embodiment, a report and/or form may begenerated which lists a revised carrier or revised route assignmentwhich may, for example, ensure recipients will get their mail ordeliveries at the same approximate time each day.

In one embodiment, a method is provided for daily management of thedelivery of articles over routes. The method comprises developing afirst database that identifies routes for delivery of articles,developing a second database that identifies the volume of articles tobe delivered along each route, and developing a third database thatidentifies a set of carriers and the carriers' availability and workloadcapacity, wherein workload capacity comprises a total number ofavailable work hours for that carrier. Next, an estimated work time isdetermined for completing the identified routes. Display screens areprovided to selectively show the data from the first, second, and thirddatabases. A user can then assign carriers to routes, while alsodetermining a variance between the estimated work time for completingthe identified routes and the available work hours for the carrier orcarriers assigned to each route. If needed, the user can adjust theassignment of carriers such that the variance for each of the routeapproaches zero.

A system can also be provided for daily management of the delivery ofarticles over routes. The system can include a first database thatidentifies routes for delivery of articles, a second database thatidentifies the volume of articles to be delivered along each route, anda third database that identifies a set of carriers and the carriers'availability and workload capacity, wherein workload capacity comprisesa total number of available work hours for that carrier. The system canfurther include a component for determining an estimated work time forcompleting the identified routes, a display screen for selectivelyshowing the data from the first, second, and third databases, acomponent for assigning carriers to routes, and a component fordetermining a variance between the estimated work time for completingthe identified routes and the available work hours for the carrier orcarriers assigned to each route, as well as component for adjusting theassignment of carriers such that the variance for each of the routesapproaches zero.

In one exemplary method for using the present invention, a supervisormakes an assessment of the mail volume to be delivered on a particularday. The supervisor can then enter this information into the CaptureMail Volume—Manual feature of the system. Next, the supervisor can viewthe Workload Status window to view the list of carriers that don't havea full day's worth of work, based on mail volume. This status can beindicated by a numerical value, as shown in FIG. 147.

Determination of the estimated work hours for each carrier can becalculated by taking into account several factors. For example, afterthe mail volume for a particular route has been estimated, a numericalcalculation is made to determine the estimated office time for thatcarrier assigned to that route for that day. The calculation can includerates for letters and rates for flats (i.e., non-letter sized flatpieces of mail such as for example magazines) per minute. For instance,a typical rate can be eighteen letters/minute and 8 flats/minute. Thesenumbers, combined, reflect the sorting time that is allocated to thatcarrier. Bundle up time can also be included into this total. Forinstance, a typical bundle up rate of 70 pieces of mail/minute can beapplied to the mail volume to determine that carrier's bundle up time.The combined sorting and bundle up time can then be multiplied by apercent to standard factor. This factor reflects a carrier'sdemonstrated ability, which has been calculated based on previousperformance statistics. A normal carrier would have a 100% standard,while a faster carrier would have a lower percentage factor since hewould likely be able to do the same amount of work but in less time. Thesystem captures this efficiency and reflects this in the percent tostandard factor for that carrier. Fixed office time, such as forcollecting signatures from customers and signing for deliveries, as wellas other miscellaneous time, can be factored into the carrier'sestimated work hours as well.

The system is configured to know how much time it should take tocomplete any given route. The route time can be a fixed or standardtime, based on inspection or by timing each activity. So, afterdetermining a carrier's estimated work hours, it is possible for asupervisor using DOIS to view the route assignments for the day and alsosee which carriers are over or under their expected work hours based onthe estimated work hours calculated for that day. The supervisor canalso view the availability of the carriers. Using DOIS, a supervisor canthen make assignments so that the total estimated overtime and undertime for the carriers approaches zero. That is, the supervisor can makeroute assignments to carriers so that no carrier is over his expectedwork hours and no carrier is under his expected work hours for that day.

After the supervisor has made the adjustments, he can advise the carrierof the changes and print out a Workload Status Report that notes whatthe new assigned routes will be for each carrier. This report would tellthe carrier which routes they need to cover for that day.

Performance Reports System

The office management module 200 of DOIS can also include a performancereports system 320. As generally illustrated in FIG. 4, the system 320can pull together data, such as for example mail volume from a mailvolume tracking system 322 and time worked from a timekeeping system 324to generate a number of reports. The performance reports system 320 canallow a user to, for example, view, generate, or modify individualcarrier/route, group, and delivery unit performance reports 330, 332,334, and to view and edit performance forms. For example, the user mayview, generate, or modify, the performance report for a given period oftime for a particular carrier, a particular route, a delivery unit, allcarriers, regular carriers, substitute carriers, or part-time carriers.

A performance report may typically comprise a graphical representation,such as for example a bar graph or trend graph. The performance reportsenable a supervisor or manager to determine how close actual performanceis to budgeted or projected performance. The reports also enable a userto determine how close actual performance is to projected performance.Further, it is possible using the reports to compare what happenedyesterday with what is happening today. With this information, a usermay elect to change one or more aspects of the delivery process to meetor exceed the desired expectations.

The individual and delivery unit performance reports may, for example,reflect performance of an individual carrier or group of carriers overthe course of a day, week, month, or year. As used herein, a week maydenote a “service week,” which runs from Saturday through Friday, or maybe defined with the system 320 to include any consecutive set of days. A“month” may denote a calendar month. If the calendar year chosen is notyet complete, the system 320 can provide all of the collected data up tothat point in time.

The performance reports system 320 can provide performance reports,including late-leaving/late-returning reports that can be used inconjunction with the time keeping system to determine whether a carrierleft on time and returned on time as projected. The system 320 may alsogenerate an absence analysis that identifies a carrier's leave taken by,for example, a pay period for a given year. The user may also print adispatch feedback report or a statistics worksheet for a given week.

With the system 320 provided, a user can generate a report such as aroute/carrier daily performance report which compares a supervisor'sprojections from the previous day to the carriers' actual clock rings todetermine and display any variance between the two. What is meant by aclock ring is a registration event on a time clock of a start or endpoint. For example, the carrier may have four clock rings per days, suchas, e.g.: (1) when he begins work; (2) when he leaves the office tobegin his route; (3) when he returns from his route to the office; and(4) when he leaves the office for the day. However, any known method canbe used to calculate and record each carrier's total time worked.

Another type of report that can be generated using the performancereports system 320 is a unit daily performance report and unit weeklyperformance graph consolidate the unit's performance on a daily andweekly basis, respectively, based on a number of performance factors,such as individual carrier performance and the amount of mail that wasdelivered. The dispatch feedback report lists the amount of mail volume(in terms of percent of the delivery unit's total mail volume for a day)coming in from its sorting facility. Tracking the percent of the dailymail volume arriving in each delivery unit from the sorting facilityallows a supervisor to improve the delivery unit's mail flow.

In one embodiment, a method is provided for managing delivery ofarticles comprising developing a first database that identifies anactual amount of delivery resources used by a client for a predeterminedperiod, developing a second database that identifies a budgeted,scheduled or projected amount of delivery resources to be used for theperiod, providing display screens selectively showing the data from thefirst and second databases, comparing the actual amount of deliveryresources used versus the budgeted, schedule or projected amount ofdelivery resources to be used for the period, and generating a reportbased on the comparison between the actual amount of delivery resourcesused versus the budgeted, schedule or projected amount of deliveryresources to be used for the period.

A system for managing delivery of articles can also be provided. Thesystem can include a first database that identifies an actual amount ofdelivery resources used by a client for a predetermined period, a seconddatabase that identifies a budgeted, scheduled or projected amount ofdelivery resources to be used for the period, a display screen forshowing selective data from the first and second databases, a componentfor comparing the actual amount of delivery resources used versus thebudgeted, schedule or projected amount of delivery resources to be usedfor the period, and a component for generating a report based on thecomparison between the actual amount of delivery resources used versusthe budgeted, schedule or projected amount of delivery resources to beused for the period.

Planning and Scheduling System

Another component of the office management module 200 of DOIS is aplanning and scheduling system 340. As generally depicted in FIG. 5, theplanning and scheduling system 340 of the present invention can permit auser to manage scheduling of, for example, a workload 342, an overtimedesired list (ODTL) 344, and an annual budget 346, on a weekly basis. Inone embodiment, a user may override overtime calculations that were notperformed, or performed incorrectly, by the planning and schedulingsystem. The planning and scheduling system 340 allows users to schedulecarriers' work schedules for the next following week, while taking intoconsideration budget factors and managing overtime rules.

With the planning and scheduling system 340 of DOIS, a user may viewprojected workload 342 based on volume from another historical period,such as the previous year, and may assess the effect of a particularevent, such as a heavy snowstorm, during that period. A user may alsoview, generate, edit, or print a weekly schedule report for the currentweek or another week such as for example the following week. This weeklyschedule may account for projected mail volume during the selected week.The weekly schedule report can include the names of regular carriers andthe routes to which they are assigned. The weekly schedule report mayalso include the day-to-day schedule of a particular carrier. Additionalinformation about carriers and/or routes may also be present in theweekly schedule report.

The planning and scheduling system 340 may also allow a user to view ormodify assignment details for a given route number, such as theparticular section that is assigned to a carrier, and whether it is anoffice or street section. If a carrier assigned to a particular route isabsent, or on leave, the user can assign another carrier to the routefor the duration of the first carrier's absence. In one embodiment, auser may select a route and assign a carrier to that route. A user mayalso assign overtime hours to a carrier, which may be scheduled beforeor after a carrier's regular shift. A user of the system 340 may modifya carrier's assignments for a particular week. For example, a user mayreassign a carrier to a route that the carrier has requested or mayremove a carrier from a route. The planning and scheduling system may,in one embodiment, warn a user that the system has detected overlappingor conflicting assignments.

The planning and scheduling system 340 may also warn the user that aparticular assignment will place an employee into “penalty overtime.”Penalty overtime, in one embodiment, may be defined as total workingtime of more than ten hours a day, or more than four days of overtime ina week. A user, in one embodiment, may authorize or reject anassignment, following the system's warning.

The system 340 can provide a method of managing an overtime desired list(ODTL) 344. A user may generate a new OTDL or modify an existing one.For example, a user may add a carrier to or remove a carrier from theOTDL. If a carrier was removed from the overtime desired list, thesystem 340 can be configured to display the date of removal. A user mayalso use the system 340 to generate a new OTDL for a different timeperiod, such as for example a new quarter, but may also roll in anovertime list from the previous quarter in order to avoid re-enteringthe entire list.

The system 340 may allow a user to display a list of each carrier thatdesires overtime and to track overtime hours and opportunities forovertime hours by each employee on the overtime desired list. A user mayview each carrier's overtime status, including the amount of overtimethat that carrier is willing to work. A user may also identify employeeswho have refused overtime on a given day, and the reasons for theirrefusal. A user may select a period of time (such as for example a yearquarter) and display information for all carriers desiring overtime forthat period. A user may also track overtime by carrier by quarter.

In some embodiments, the planning and scheduling system 340 can providea warning when a route exceeds a predetermined threshold amount and/oroccurrence of overtime. This warning would indicate to a supervisor thathe should investigate whether the route requires permanent assistance orshould be divided. In one embodiment, a user, such as for example anational supervisor, may change the threshold and accordingly, adjustthe route.

The system 340 may also allow a user to manage an annual budget 346. Auser with the appropriate authorization may also view, edit, modify, orrecord a delivery unit's budget by week. A user may also, for example,display a weekly summary by month or a daily summary by week. Theplanning and scheduling system 340 can also allow the user to allocate aweekly budget or display budget details. A user may also break down thebudget by day, month, or fiscal year, to plan for work hours and mailvolume. Budget can be represented in terms of total work hours providedto a particular unit, for that given period of time. The budgeted hoursrepresent a restriction or maximum threshold on the total work hoursthat can be allocated for any given unit for that work period.Accordingly, a supervisor can use DOIS to allocate resources so thatdemand is met while also keeping within the budgeted work hoursrestriction. Further, the system 340 can allow the user to compare thebudgeted hours against the carrier's actual hours, and the budgetedhours against the scheduled hours. The actual hours worked can also becompared with the projected hours to have worked.

In one embodiment, a method is provided for managing delivery ofarticles to locations along routes over a plurality of days. The methodcan comprise the steps of developing a first database that identifiesroutes for delivery of the articles, developing a second database thatidentifies regularly scheduled carriers, assigning carriers to theroutes in response to the data from the first and second databases,providing display screens selectively showing the carriers assigned tothe routes and showing the number of hours projected for those carriersto complete those routes over the plurality of days, developing a thirddatabase that identifies the assignments and projected hours, developinga fourth database that identifies budgeted work hours for the carriers,and providing display screens selectively showing data from the thirdand fourth databases in a form that permits comparison of the hoursprojected and hours budgeted for the delivery of the articles along theroutes over the plurality of days.

Also provided is a system for managing delivery of articles to locationsalong routes over a plurality of days. The system can comprise a firstdatabase that identifies routes for delivery of the articles, a seconddatabase that identifies regularly scheduled carriers, a component forassigning carriers to the routes in response to the data from the firstand second databases, a display screen for selectively showing thecarriers assigned to the routes and showing the number of hoursprojected for those carriers to complete those routes over the pluralityof days, a third database that identifies the assignments and projectedhours, a fourth database that identifies budgeted work hours for thecarriers, and a display screen for selectively showing data from thethird and fourth databases in a form that permits comparison of thehours projected and hours budgeted for the delivery of the articlesalong the routes over the plurality of days.

Route and Unit Maintenance System

The office management module 200 of DOIS can also include a route andunit maintenance system 360. As generally depicted in FIG. 6, the routeand unit maintenance system 360 can provide several functions, such asfor example it can allow a user to manage route maintenance 362,implement a pivot plan 364, implement an operating plan 366, and manageunit maintenance 368. In addition, the system 360 can generate reportsand forms, including information relating to route base informationmaintenance, pivot plan maintenance, non-delivery point maintenance,data capture and transfer, and mail volume.

In an exemplary embodiment, the system 360 can manage route maintenance362 and can list all of the routes stored on the mainframe. A user canselect certain of those routes to be downloaded to the workstation. Withthe route and unit maintenance system 360, a user may view informationfor a particular route, including the type of route (e.g., residential,business, mixed), the type of delivery (e.g., foot, dismount, curb linemotorized, park and loop, etc.), whether the route is a full route orauxiliary, and whether or not the route has Saturday delivery. The usermay also view the route's begin time, leave time, return time, and endtime on a daily basis, and the route's last inspection date andstatistics, and fixed office time (the amount of fixed office time thathas been established for the route, which is not driven by workload).The user may further view morning and evening mail volume information,percent-to-standard, and carrier information such as the regular carrierassigned to the route, the carrier's hire date, the date the carrier wasassigned to the route, and the replacement carrier, if any. A user mayalso see if a route is pending special inspection, or may view or enterinspection information.

A user of the route and unit maintenance system 360 may also view andadjust information related to a route, for example, travel times andbegin times. A user may modify the step-by-step travel pattern a carrierfollows to deliver a route. A user may further remove a route from adelivery unit. This might be done, for example, when a new ZIP code™ iscreated and routes are therefore moved to a new unit. A user may assignor edit one or more of the following fields: route number, its ZIPcode™, type (e.g., collection route, relay route, or combination route),base hours, daily begin tour time and Saturday begin tour time. A usermay set the time when a carrier is predicted to drop mail in the firstdelivery box of a route.

The route and unit maintenance system 360 can also allow a user tocreate a pivot plan 364 and logical groups, or assign route breaklocations. That is, the route can be broken up into a series of logicalsegments. The system 360 takes the step-by-step travel pattern a carrierfollows to deliver a route and combines that information with aninterfacing Address Management System (AMS) database to identify theaddress of every delivery on a particular route, and then splits thosedeliveries into logical groups. Once the user creates logical groups ofaddresses, the system 360 can assign an amount of time for delivery, atravel pattern, a delivery method, possible points for mail delivery(e.g., number of houses), the carrier's expected enter time and exittime for a particular logical group, and his first delivery. A blockwith no breaks can be considered a sector segment. Sector segments arealready set up in the AMS database and are linked together by the userto create a logical group.

A user of the system 360 may identify all of the routes in closeproximity to the route being pivoted, so that the user can reassign asection to another carrier having a proximate route, and thereforelessen the time it takes to assist the carrier with the route section. Auser may also view, create, or modify non-delivery points, such as forexample park points (where a carrier parks and makes a loop on foot),relay points (where the carrier returns to the vehicle between multipleloops), and collection boxes (where carriers pick up mail to beprocessed).

The route and unit maintenance system 360 can also allow a user tointegrate an operating plan 366 to coordinate mail sent between a postoffice and a sorting facility. The system 360 can update informationregarding when deliveries will arrive from the sorting facility and howmuch mail will be in each delivery. A user may view a list of dispatches(deliveries from the sorting facility, as discussed above), theirarrival time, and the percentage of the day's mail that is expected fromthe plant. A user may manually enter or edit mail volume information.The mail volume can be broken down by route and day, and can beidentified by morning or evening volume. The system can break down mailvolume by type of mail. A user may print a one-day office mail count foran individual carrier. A user may measure the impact the automated DPSsorter has on the total number of letters the carrier has to sort, sothat the saved time can be subtracted from a carrier's allowed sortingtime. A user may view, for example, by ZIP code™ or by route, the impactof having DPS sorted mail.

A user may designate a threshold for one or more types of mail. If themail volume of a type of mail exceeds the entered threshold (which isentered as a percentage), the system highlights the mail volume field toalert the user of a possible mistake. The highlighting may includeturning the field yellow, bolding it, flashing it, or another method todraw the user's attention.

A user of the system 360 may also manage unit maintenance 368, asrepresented in FIG. 6. For example, a user can view route informationrelevant to a particular delivery unit (e.g., a route inspection, aminor adjustment, etc.) over a period of time, type of route, startdate, end date, route status, and date implemented. A user may view alist all carriers, their type, and their assignment. Carriers can beadded, edited, or deleted using the system 360. For example, asubstitute carrier may be added. When a user adds a carrier, he or shemay enter information for that individual carrier into the system 360.

Further, a user of the route and unit maintenance system 360 of thepresent invention may designate a threshold of overtime and under timehe or she wants to be alerted to. For example, if a user selects to viewthirty minutes, only routes that have 30 minutes or more of overtime orunder time will be displayed. A user may also view or enter vehicleodometer readings at various points in a carrier's workday, for example,upon reporting to the office, leaving the office, making a firstdelivery, etc. during an inspection period. The system may also displaya carrier's volume of mail for a given date and route number during aninspection period.

In one embodiment, a method is provided for managing delivery ofarticles. The method comprises the steps of developing a database thatidentifies routes for delivery of articles, including characteristics ofthe routes, providing a display screen selectively showing the routesfor delivery and the characteristics, using the display screen to modifythe characteristics of a delivery route, and saving the modification tothe database.

A system for managing delivery of articles can also be provided. Thesystem can include a database that identifies routes for delivery ofarticles, including characteristics of the routes, a display screen forselectively showing the routes for delivery and the characteristics, acomponent for modifying the characteristics of a delivery route, and acomponent for saving the modification to the database.

Thus, the route and unit maintenance system allows a user to makepermanent prospective adjustments to the assignment of routes tocarriers, and to the manner in which a carrier travels to and from aroute. In one example, the user can break up a route into a series oflogical segments, then assign segments of the routes to carriers so thateach carrier has approximately eight hours of work. This feature allowsthe user to level off the workload. It is contemplated that this system360 can be implemented on an as-need basis to provide a permanent changeto the route assignment.

Managed Service Points and Street Management System

Another feature of the office management module 200 of DOIS is themanaged service points and street management system 380, which can allowa supervisor to track a carrier's progress through the use of barcodesplaced at various points along a routes (e.g., in mailboxes orcollection boxes). As depicted in FIG. 7, carriers can carry a mobiledata collection device (DCD) 382 or other handheld interfacing devicefor collecting information. The use of mobile technology can allow thetracking of mail in the field through signature and deliveryconfirmations. In addition, when a carrier reaches a managed servicepoint (MSP), he or she can scan an MSP barcode label 384 with a mobilehandheld interfacing device, and the system 380 can record the time thecarrier was at that location. Once back at the postal facility 386, themobile data collection device 382 can be docked, and the information maybe viewed and analyzed by a supervisor, who can then can determine howlong it takes a carrier to reach different delivery points, and canquickly rectify inefficiencies. Further, the system 380 enables a userto maintain consistency in terms of the delivery time for a particularlocation on a route, by monitoring the window of time in which a carrierreaches an MSP location over a given period of time.

In one embodiment, MSP barcode labels 384 are secure. For example, it iscontemplated that all MSP barcode labels 384 must be generated by anauthorized user or facility of the system 380. Further, a new MSP label384 may only be requested by an authorized user, such as for example asupervisor. In another embodiment, a new MSP label 384 may only beapproved by an authorized user, such as for example a systemadministrator.

The managed service points and street management system 380 of thepresent invention may also share data with other applications, such asfor example the mail volume collected by a supervisor, the time andattendance recorded with Time and Attendance Collection System (TACS),the Address Management System (AMS), and scanned data from mailcarriers.

In one embodiment, a method is provided for managing delivery ofarticles. The method comprises the steps of providing a set of scannablebarcode labels corresponding to unique addressable locations on adelivery route, providing a database of recorded time entries, eachentry corresponding to a scanning event of a barcode label, and trackinga movement of a carrier by analyzing a series of recorded time entriesfor the delivery route.

A system for managing delivery of articles can also be provided. Thesystem can comprise a set of scannable barcode labels corresponding tounique addressable locations on a delivery route, a database of recordedtime entries, each entry corresponding to a scanning event of a barcodelabel, and a component for tracking a movement of a carrier by analyzinga series of recorded time entries for the delivery route.

Route Adjustment System

As depicted in FIG. 2, DOIS can also include a second module for streetmanagement 400, which can include a route adjustment system 500. In oneembodiment of the present invention, the route adjustment system 500provides for route inspections and adjustments as depicted in FIG. 8.The route adjustment system 500 can allow a user to view, edit, orrecord examiner observations and comments 512 after a physicalinspection of the route 510. A user may also view a route inspectionsummary in week or day view by date using the route adjustment system500. The route adjustment system 500 of the present invention allows theuser to redefine the route itself, allowing permanent changes to thephysical parameters which define the route. This can be performed afteran inspection has been made, or after a minor adjustment has been madeand approval is given to make the adjustment permanent.

A user may also use the route inspections and adjustments system 500 toperform a route adjustment 514. With this route adjustment system 500, auser may create a new route 516. The new route can be automaticallyprovided with a new route number via the address management system(AMS). The user can also make adjustments to the new route with theroute adjustment system 500, as shown in FIG. 8.

A user may use route inspection data for a given route to createadjustment scenarios for that route in order to determine the mostefficient route. A user may want to evaluate an alternate scenario, forexample, in the event of new construction along a route. To create a newscenario (e.g., by moving a particular street from one route to anotherroute), the user can enter a ZIP code™ and each route within that ZIPcode™ can be displayed along with its office time, street time, alliedtime (i.e., time when the carrier is on the street but not deliveringmail, for example, refilling mail between loops), possible deliveries,and other factors. The user can evaluate and adjust office, street, andallied time, and can assign a given amount of time to a route. Streetinformation can be displayed, for example, by block range.

A route adjustment may be formal, special, or minor. A special routeadjustment request can one made by a carrier. A supervisor need notaccompany the carrier on the route, but may instead use predeterminedcalculation to make the adjustment using the volume of mail and thehistorical time data for that route. In one embodiment, for a formal orspecial adjustment, the user manually enters the adjustment. In anotherembodiment, if the user identifies a minor adjustment, no data need beentered because there is no normal inspection process associated with aminor adjustment.

A user of the route adjustment system 500 can enter, edit, or viewadjustment details from multiple delivery facilities including, forexample, the route, carrier, adjustment type, duration, and whether theadjustments are implemented or pending. A user may also enter commentsfor an adjustment. A user may analyze data such as DPS volume impact,and edit office time, select and edit street time, and add or removedelivery points. A user may manually enter or edit mail volumeinformation, or modify the step-by-step travel pattern a carrier followsto deliver a route. A user may adjust details relating to a route byidentifying the route and the carrier, along with the adjustment type,duration, and status (implemented or pending). A user may also enter ormodify comments related to an adjustment.

The system 500 may also allow a user to view a listing of adjustmentsthat have been implemented or are currently pending, for example, by ZIPcode™. A user may also input a delivery unit and display a summary ofadjustments made for the entire unit. Further, a user may add or removedelivery points from a route. The system 500 can be configured toautomatically calculate and display changes to office time and streettime based on the addition or removal of the delivery point. The usermay also add, edit, or remove non-delivery points, non-delivery pointattributes, and non-delivery point sector segment association.

A user of the route adjustment system 500 may also add, edit, or removenon-delivery point attributes, and non-delivery point sector segmentassociation. Non-delivery point attributes include the non-deliverypoint type (e.g., collection point, relay box, park and loop point),time the carrier arrives at the non-delivery point (daily, on Saturday,and on holidays), possible deliveries (per relay, loop, swing), locationID (for collection boxes having ID numbers), street corner, streetnumber, a pre-directory designation (e.g., “north” for North ElmStreet), street name, suffix, etc. The non-delivery points sectorsegment association breaks down the sector segments and displays them.

A user may also insert an allied time or sector segment. This can allowthe user to make a change to a route such as adding a collection box.This can also allow the user to identify delivery zone changes (moving aroute among delivery zones). A user may adjust allied times (e.g., relaytime, travel to time, vehicle load time, and vehicle unload time). Relaytime is understood to be the time it takes a carrier to prepare for arelay at his vehicle. Travel to time is understood to be the time ittakes the carrier to travel to and from lunch, to and from the route,etc. Vehicle load time understood to be is the time it takes the carrierto put his mail in his vehicle. Vehicle unload time is understood to bethe time it takes the carrier to unload his vehicle.

With the route adjustment system 500, a user can enter or editinformation relating to new construction, such as when the constructionbegan, when it is expected to end, location information, the anticipatednumber of deliveries to the new construction. The system 500 can beconfigured to designate a factor created from the route inspectionadjustment and calculate the time the new construction will add to aroute.

Further, a user may generate and display a random time card analysisdata, and print an appropriate report. The system 500 can randomlyselect a carrier and display the week number for the specific accountingperiod and the week date. The system 500 can also display any “abnormalconditions” that would suggest a user select a previous or later week toavoid any SPLY impact that may distort the data for that week. Thesystem 500 in one embodiment can perform an automatic week adjustmentsuch that, if the regular carrier was not working his route on thechosen week, the system 500 can skip to the next week. A user may alsocheck for any abnormalities during the chosen weeks. A user may also seewhen a carrier is given auxiliary assistance to deliver mail.

A user can, in one embodiment, print reports from this system 500. Thereports can relate to, for example, route performance, route inspection,unit recap, non-delivery point changes, calendars of events that musttake place in order to meet contractual requirements, adjustmentanalysis, mail counts, and inspection summaries.

A user may generate a weekly schedule for a delivery unit by entering aservice week start date into the system 500. The user can select a routenumber and can then also select a replacement carrier. If no replacementcarrier is selected, the system 500 can default to the regular carrier.

The route adjustment system 500 can also allow a user to add a newdelivery unit, and related information such as for example the newdelivery unit's area ID, district ID, facility ID, group ID, andassigned finance number. This information can be used to link deliveryunits to other units and facilities within their district. In oneembodiment, data can be gathered for creating a new delivery unit bypulling in data from the AMS database and other interfacing databasesthat have relevant information about routes, etc.

In one embodiment, a method is provided for managing delivery ofarticles. The method comprises the steps of developing a database thatidentifies routes for delivery of articles, wherein each route compriseslocations for article delivery, providing a display screen selectivelyshowing the routes for delivery, using the display screen to modify thelocations for article delivery, and saving the modification to thedatabase.

A system for managing delivery of articles can also be provided. Thesystem can include a database that identifies routes for delivery ofarticles, wherein each route comprises locations for article delivery, adisplay screen for selectively showing the routes for delivery, acomponent for modifying the locations for article delivery, and acomponent for saving the modification to the database.

Although the system of the present invention has been described for usewith mail or package delivery service providers, it is understood thatthe system can easily be implemented by any type of delivery serviceprovider. For example, the system can be utilized by any deliveryservice provider that would benefit from a high-tech matchmakingapplication that pairs up deliveries to be made with the carriersavailable to perform the deliveries, such as the food delivery industry.

To use the delivery operations information system 100 of the presentinvention, a user may be required to enter a user identification and apassword on a login screen. If the user identification is recognized andthe password accepted, the user may enter the DOIS program and be givenaccess to the mainframe. Preferably, each user has a uniqueidentification and a password, so that the system can track who is doingwhat within the system. The login screen can allow the user to changehis password if desired.

In one embodiment of the present invention, once the user has loggedonto the mainframe, he sees a screen confirming that the application isloading. The user may then see a screen indicating that the system issecure and unauthorized use is prohibited.

FIG. 9 illustrates an embodiment of the Workload Status window of thepresent invention. In an exemplary embodiment, a user will only be givenaccess to information in the system that concerns the delivery unit(s)that he supervises. Within the Workload Status window is a “Routes” tabfor individual routes. This tab lists all of the routes for the user'sdelivery unit(s), the carrier assigned to each route, and whether theroute is over or under eight hours on a given day, based on the systemscalculated workload. In the center of FIG. 9 are fields that tell thesupervisor the total overtime and under time for the total of thedelivery unit's routes, so that the supervisor can try to reassignworkload to get those two numbers to zero. In the bottom portion of theRoutes tab are listed any route vacancies. Vacancies are when a route isnot covered by an individual carrier. This can be used to plan vacanciesor to inform the supervisor of vacancies that occur on a particular dayas a result of a call-in.

FIG. 10 illustrates a “Change Percent to Standard” window. Within any ofthe DOIS windows, a right click with the mouse will give the usercertain abilities that are not explicitly listed in the window.Preferably, Workload Status is a window that the user can right click toget the Change Percent to Standard window, which sets forth a carrier'sability to handle a given workload. Once the user selects the route inthe Change Percent to Standard window, he can click on the displaybutton and the system will identify the regular carrier's percent tostandard as established through a count and inspection. If a replacementcarrier is handling a route, the user can change the percentage tostandard using the up and down spinner box to determine thereplacement's ability to handle that route's workload. Once the usermakes a selection in the Change Percent to Standard window, he can press“save” to process any changes made or press “cancel” to leave the windowwithout saving any changes.

FIG. 11 illustrates a Carrier Information List that allows the user toassign assistance from scheduled and unscheduled carriers. This windowsincludes fields for the duration of the assistance, whether it becovering the whole route or just a portion of the route. It also has abutton on the right side that the user can view the unscheduled carriersand call them in if he needs them, for example, to cover a full route.If the user needs to cover a portion of a route or split a route up insome way, the carriers' names that are assigned on that date will showup in the carrier information list, along with what type of employeethey are—whether they are regular, part-time flexible, or an unassignedregular carrier. The list also tells the user the number of days acarrier has physically worked on the route, the last day the carrierworked the route, the days they worked on the route in the office, andthe last day they worked the route on the street. Preferably, theCarrier Information List also sets forth the carrier's overtimepreference. There may additionally be a Record Overtime Exception buttonthat can record a carrier's reasons for refusing to accept overtime.

FIG. 12 illustrates a Supervisor Work Bench screen of an embodiment ofthe present invention, having a series of tabs across the top toseparate each individual section. The sections may include, for example:Daily Workload Management; Performance Reports; Planning and Scheduling;and Route and Unit Maintenance. The Daily Workload Management tab ischosen and displayed in FIG. 8. As illustrated, this tab is divided intosubsections covering every system function that the user needs to manageworkload. Workload management involves the function of volume recordingwhich is covered in the Mail Volumes and Work Hours section. Thissection allows the user to capture mail volumes manually by pressing adesignated button. Pressing the button produces another window thatshows or allows the supervisor to input volumes. The user may alsocapture mail volumes using a mobile data collection device (“DCD”). TheDCD is an automated way of recording mail volume. As the supervisorcounts the mail volume, he uses the DCD to enter the mail volume byroute after which the DCD is uploaded into the system.

The next button in this section is a Same Period Last Year (“SPLY”)impact entry function that records anomalies occurring on a given day,such as a major snowstorm. SPLY information is used for future planning.

The next section in the Daily Workload Management tab is Reports andForms. The first form, “1564A Delivery Instructions,” identifies keyinformation about a given route including, for example, the carrierassigned, the replacement carrier, relay points, the number ofdeliveries on each relay point, park points, where the carrier goes tolunch, and how the carrier travels back and forth to lunch. The nextform is the Revised Carrier/Route Assignment that ensures customers willget their mail at the same approximate time each day. The next button isfor the Workload Status Report, which is an expansion of the workloadstatus window. Preferably, it gives all the basic information for everyroute and every assignment that's made for a given day. The report canhave several sections, including the carrier, the route, the status ofthe carrier, the type of carrier, the demonstrated performance of thecarrier, the volume the carrier has for the day, projections based onthe carrier's workload, the carrier's leave time, projections of thecarrier's return time, and projections of the carrier's total time forthe day. The last button is for the Workhour Discrepancy Report, whichidentifies deviations from expected work.

The next section of the illustrated embodiment of the Daily WorkloadManagement tab is the Workload Management section. “Create Vacancy” isthe first button and includes documentation for carrier leave requests.“Regular/City Route Details” includes information that identifieseverything about a route, for example, the base route information,including office time, street time, how many deliveries the carrier has,the carrier's begin time, leave time, and return time. “MiscellaneousRoute Details” includes basic information for such routes as combinationroutes, collection routes, and relay routes. The “Street Pivoting”button assists the user in breaking a route up into small segments(e.g., by hour) that can be given to other carriers for delivery. The“Daily Assignments” button provides the user with a quick snapshot ofeach carrier's assignment that day and the expected total work time.

This section may also include a “Record Overtime Refusals” button thatperforms the same function as the Record Overtime Exception button onthe Carrier Information List. The next button is “Adjust Leave/OfficeTime” that can be used by a supervisor to adjust the carriers' time whenhe has, for example, a service or safety talk with the carriers. If thesupervisor spends twenty minutes giving the talk, he can then adjust allof the routes by twenty minutes. The “Adjust Return/Street Time” buttonis used to adjust a carriers time when a carrier has to deviate from hisplanned route, for example, due to construction. The “Change Start Time”button is used to adjust a carriers schedule if his start time deviate,for example, due to lateness.

FIG. 13 shows the “Capture Mail Volume” window discussed above withrespect to FIG. 12 for manual recording of mail volume. This windowcaptures and displays mail volume for each route, preferably by categorysuch as first class letter mail, first class flat mail, parcels, etc. Italso preferably provides the user with running totals. Mail canpreferably be measured in pieces or in linear measurement. This featureof the system preferably also allows the user to “roll in” undeliveredmail from the previous day or, if evening mail volume is being captured,the user can roll in undelivered mail from the morning.

In a scenario where mail is received by individual post offices from acentral sorting facility, the system of the present invention allows theuser to record the amount of mail that comes in for each delivery fromthe sorting facility, and the time of the delivery. In this way, theuser can track inflow of mail.

FIG. 14 shows a Capture Mail Volume window discussed above with respectto FIG. 12 for automated recording of mail volume using a DCD. Once theuser counts the mail with the DCD, he can record the volume and uploadthe data. The system preferably includes a set of instructions for thedata upload.

In the exemplary embodiment of the invention, the system can be used toconfigure the DCD for mail volume recording. The DCD is a device capableof performing two functions: it can record mail volume and it can beused during a supervisor's route inspection process. If a single DCD isused to perform both functions the system 100 can be used to configurethe DCD for the different functions. For example, the system 100 caninclude a “DCD Configuration—Mail Volume” function which, wheninitiated, gives a specific set of instructions on how to configure theDCD. The system 100 can also include a “DCD Burn-In” function forconfiguring the DCD for a route inspection.

FIG. 15 illustrates a SPLY Impacts window. Entering this window canallow the user to record special events, such as snow storms, so thatsupervisors pulling data for that day at a later time will be alerted tothe special event.

FIG. 16 illustrates a 1564A Delivery Instructions window from theSupervisor Workbench screen. This window is retrieved when the userright clicks the mouse button. The user identified the route number andpresses the Print Preview button for a visual copy of the PS Form 1564Ain form flow.

FIG. 17 illustrates a Revised Carrier/Route Assignment window, whichproduces a report that shows a carrier or his supervisor the carrier'srevised route. The report can be printed either by carrier or by routefor a given date. In one embodiment the report can be printed with orwithout route times.

FIG. 18 illustrates a Work Hour Discrepancy report window. The reportproduced by this window shows a carrier's performance over a period oftime and its difference from expectations.

FIG. 19 illustrates a Create Vacancy window of the present invention.The user can choose a carrier's name using a drop-down list, and canthen create a vacancy type such as sick leave and annual leave. Thiswindow preferably also allows the user to indicate whether the carrieris taking a full or partial day of leave and, for a partial day, thewindow may further record the number of hours of leave taken. The usercan identify a date range for a carrier's multi-day leave in the “DateFrom” and “Date To” fields. The system may be designed to print theappropriate leave form automatically upon saving vacancy information.

FIG. 20 illustrates a Route Daily Details window, which is used toassign a carrier to a route. The Route Daily Details window displays,for a given route and day, whether the regular carrier is assigned tothe route, absent, or on leave. In this window, the user can preferablypress an appropriate button to assign another carrier to the route, orquick assign a carrier or remove a carrier.

A Miscellaneous Route Details windows is shown in FIG. 21 and is used toassign carriers to miscellaneous routes such as collection routes orcombination routes. This window preferably also allows the user toassign assistance to the miscellaneous routes.

FIG. 22 illustrates a Pivot Option window, which appears when the userelects to “pivot” a route. “Pivoting” is reassigning a portion of aroute. The system preferably allows the user to pivot by section orduration—section being a given street on the route and duration beingtime to deliver the street. The system may also allow the user to pivotthe route by business deliveries or residential deliveries.

A Street Pivoting window can appear if the user selects a given routefrom the window of FIG. 22. This Street Pivoting window allows the userto choose a pivot option, for example, by section, and then allows auser to select the number of sections that he wants (e.g., one, two,ten, or twenty sections). Alternatively the user can pivot by duration(e.g., one-hour, two-hour, or three-hour increments). In one embodiment,the system will then break down the route being pivoted into everydelivery, and the mode and method of delivery for all the streets,broken down into individual sections called logical groups. The systemwill give the user start and end times, how long it takes to delivereach logical section, the type of delivery (e.g., business orresidential), and the delivery method (e.g., mounted or park and loop).

FIG. 23 illustrates a Daily Assignments window that displays the routeeach carrier is assigned to. In one embodiment, the fields displayedinclude: carrier's name, type of carrier; if the carrier desiresovertime; the carriers overtime status; the carrier's start time thatday; the route the carrier is assigned to; the carrier's assignmenttype; and the carrier's assigned hours.

FIG. 24 illustrates a Record Overtime Exception window of one embodimentof the invention, as discussed above. If a carrier is offered overtimeand elects not to take the overtime, his reason can be recorded.

FIG. 25 illustrates a Adjust Leave/Office Time window, which allows theuser to adjust leave time for a given date and carrier, as discussedabove. An Adjust Return/Street Time window of one embodiment of theinvention is shown in FIG. 26, which allows the user to input time addedto a carrier when the carrier is providing assistance to another route.

FIG. 27 illustrates a Change Start Time window allowing a user to changecarriers' begin time for a given day, as discussed above. The system 100can also include an Assign Carrier Start Time window allowing the userto set a carrier's scheduled start time.

FIG. 28 illustrates a window for an Interface Configuration function ofan embodiment of the invention. The system of the present inventionallows connectivity to other applications for which the system must beconfigured, and this window allows the user to perform theconfiguration.

FIG. 29 illustrates an embodiment of a user's screen on a daily basiswith both the Workload Status and Supervisor Workbench windows open. Inaddition to the Routes tab in the Workload Status window, there is alsoan Other tab where, for example, miscellaneous routes can be listed. Asshown, the Performance Reports tab of the Supervisor Workbench, caninclude, for example, the following sections: Individual PerformanceReports, Performance Forms, and Unit Performance Reports.

In one embodiment of the invention, the Individual Performance Reportssection includes individual weekly performance reports, bar graphs, andtrend graphs for a carrier. A week generally denotes a “service week,”which runs from Saturday through Friday. However, it is understood thata week can be defined in the system to include any consecutive set ofdays. The Performance Forms section may include, for example, alate-leaving/late-returning report that can be used in conjunction withthe time keeping system to determine whether a carrier left on time andreturned on time as projected. The Performance Forms section may alsoinclude an absence analysis that identifies a carrier's leave taken bypay period for a given year.

The unit performance reports may include, for example, a Route/CarrierDaily Performance Report, a Unit Daily Performance Report, a Unit WeeklyPerformance Trend Graph, a Dispatch Feedback Report, and a FLASHStatistics Worksheet. The Route/Carrier Daily Performance Reportcompares a supervisor's projections from the previous day to carriers'actual clock rings to determine and display any variance between thetwo. The system is preferably set up for a carrier to have four clockrings a day: (1) when he begins work; (2) when he leaves the office tobegin his route; (3) when he returns from his route to the office; and(4) when he leaves the office for the day. However, any known method canbe used to record each carrier's time worked. The FLASH StatisticsWorksheet is a report that displays mail volume totals.

The Unit Daily Performance Report and Unit Weekly Performance Graphconsolidate the unit's performance on a daily and weekly basis,respectively, based on a number of performance factors, such asindividual carrier performance and the amount of mail that wasdelivered. The Dispatch Feedback Report lists the amount of mail volume(in terms of percent of the delivery unit's total mail volume for a day)coming in from its sorting facility. Tracking the percent of the dailymail volume arriving in each delivery unit from the sorting facilityallows a supervisor to improve the delivery unit's mail flow.

FIG. 30 illustrates an Individual Weekly Performance Bar Graph windowthat allows the user to select, for a given week, either all carriers,regular carriers, and T6 carriers. (Carriers usually assigned fiveroutes to carry and when the regular carriers have a day off theyreplace them on that particular day) and PTFs (people that do not haveregular routes assign to them). Then a service week can be selected anda preview of this report can be printed for those individual group ofcarriers. This program accesses Form Flow software and produces a reportfor the user. Users can view this window after selecting IndividualWeekly Performance Report or Individual Weekly Performance Bar Graphbutton.

FIG. 31 illustrates an Individual Weekly Performance Trend Graph windowthat allows the user to display a Performance Trend Graph for a givenweek either by carrier or by route. In one embodiment, drop down menusidentify all of the carriers or routes within a given delivery unit.FIG. 32 illustrates an embodiment of a window that allows the users toprint a Late Leaving/Returning Form as discussed above. FIG. 33illustrates a window that allows the user to print an Absence Analysis,as discussed above, by carrier and calendar year. If the calendar yearchosen is not yet complete, the system provides all of the datapopulated up to that point.

FIG. 34 illustrates a window that allows the user to print aRoute/Carrier Daily Performance Report for a particular week. From aUnit Performance Menu window, the user can select either a dailyperformance report or a weekly unit performance trend graph, asdiscussed above. If the user presses the button for the dailyperformance report, he is taken to FIG. 35 where he selects a week forwhich to print the report. If the user presses the button for the unitperformance trend graph, he is taken to FIG. 36 where he can select aweek using the up and down arrow spinner box.

FIG. 37 illustrates a window that allows the user to print a dispatchfeedback report, as discussed above, for a given fiscal year. FIG. 38illustrates a window that allows the user to print a FLASH statisticsworksheet, as discussed above, for a given week. FIG. 39 illustrates aCSDRS Daily Worksheet window that allows the user to print a CustomerService Daily Recording System (CSDRS) report after selecting a servicedate. This report can be generated and printed on a weekly basis byselecting the CSDRS Weekly Worksheet button from the Performance Reportsmenu, as shown in FIG. 29.

FIG. 40 brings us back to the Supervisor Workbench with a view of oneembodiment of a Planning and Scheduling tab, which includes threesections: Weekly Scheduling; OTDL Management; and Annual Budget. TheWeekly Scheduling includes buttons as described below. A Weekly Schedulebutton allows the user to make assignments for the next week. The weeklyschedule can be available, for example, on Monday morning, to aid thesupervisor in managing the workforce for the upcoming week. A CreateVacancies button allows the user to create vacancies, as discussedabove. The Daily Assignments button allows the user to change dailyassignments as discussed above. The fourth button allows the user toassigned AM overtime by bringing a carrier in early with expectations ofhaving them work their overtime in the morning versus the evening. Thefifth button allows the user to print a weekly schedule report allowinghim to identify which regulars are scheduled to work and what routesthey are assigned to.

The OTDL Management section facilitates management of an overtimedesired list. The Overtime Desired List button allows the user todisplay a list of each employee that desires overtime. The OvertimeEquity Tracking button tracks overtime hours and opportunity by eachemployee on the overtime desired list and preferably produces a reportfor the user. The Overtime Equity Worksheet button identifies employeesthat have refused overtime on a given day and sets forth the reasons.

The Annual Budget section records a delivery unit's budget by week. Aninterfacing system inputs a budget to the system of the presentinvention as a weekly total. This total budget is recorded when the userpresses the Record Budget by Week button. The system allows users toallocate that weekly budget by day by pressing the Adjust Daily BudgetSpread button. The user can display budget details by pressing theBudget Details Report button.

FIG. 41 illustrates a Special Inspection Warning window that displaysany route that uses a predetermined amount and or occurrences ofovertime that the system designers have identified as calling intoquestion whether the route requires permanent assistance or should bedownsized.

FIG. 42 illustrates a Weekly Schedule window that is displayed when theWeekly Schedule button is pressed. This window may display, for example,the carrier's name, the type of carrier, and his assignment for each dayof the week. Budget information can also be displayed on the screen.This window may also display projected workload based on volume fromlast year, and any SPLY impact that occurred last year.

FIG. 43 illustrates an Assign Carriers window that displays assignmentdetails for a given route number, such as the particular section that isassigned to a carrier whether it is an office or street section. Thewindow also gives the date range for that assignment and displaysavailable carriers along with certain information about each availablecarrier.

FIG. 44 illustrates a Schedule Available Carriers window allowing theuser to view and assign work to carriers that are available. FIG. 45illustrates an Employee Daily Schedule screen that displays, for a givencarrier, information including his carrier type, work status, etc. Thesystem allows the user to create a vacancy in this window or schedulethe displayed carrier by pressing the appropriate buttons. This windowcan also illustrate a carrier's current assignment and the user canchange that assignment by pressing the Quick Assign button.

FIG. 46 illustrates an Assign Replacement window allowing the user toselect a route and pick a carrier to assign from a drop down list. Theuser can also assign a particular section of a route and set a range ofdates for the assignment.

FIG. 47 illustrates a Confirm Assignment window that informs the userwhether the system has detected any overlapping or conflictingassignments. It can also inform the user whether any assignments willplace an employee into “penalty overtime” where the carrier will workmore than ten hours a day, or will work overtime more than four days aweek.

FIG. 48 illustrates an Assign AM Overtime window, which allows the userto input the date, carrier, route, and number of hours. FIG. 49illustrates the Print Weekly Schedule window allowing the user to printthe current week or the next week. This window appears when the userselects the Weekly Schedule Report button from the Planning andScheduling tab. FIG. 50 illustrates a Regular Work Assignments windowlisting the work assignments of the carriers. This window can list, forexample, the carriers' assignment type, the route, and a day-by-dayschedule. FIG. 51 illustrates a New Regular Work Assignment window wherea user can reassign a carrier to a route that the carrier has requested.Also, if a carrier is taking multiple days of leave, this window allowsthe user to replace the regular carrier for that route for a givenperiod of time.

FIG. 52 illustrates an Overtime Desired List window. In this window, theuser selects a year quarter and the system display information for allthe carriers desiring overtime that quarter. The system may also displayeach carrier's overtime status and the amount of overtime he is willingto work. Carriers can be added to the list by pressing the New buttonand can be removed from the list by pressing the Remove button. The RollIn OTDL button allows the user to roll in overtime list from theprevious quarter to avoid re-entering the entire list.

FIG. 53 illustrates an Overtime Tracking window to track overtime bycarrier by quarter. The window displays the carrier's status (how muchovertime he is willing to work). If a carrier was removed from theovertime desired list, the system displays the date of removal. FIG. 54illustrates an Edit Overtime Information window, which allows the userto override any system overtime calculations that were done incorrectlyor not done at all. The system 100 can also include an OvertimeWorksheet window allowing the user to display an overtime worksheet fora given quarter.

FIG. 55 illustrates an Adjust Daily Budget Spread window allowing theuser to break down his budget by day to plan for work hours and mailvolume. FIG. 56 shows a Budget Detail Reports window that allows theuser to display a weekly summary by month or a daily summary by week.The user selects a print range of fiscal year and month(s).

FIG. 57 brings us back to the Supervisor Work Bench, with a view of oneembodiment of a Route and Unit Maintenance tab, including threesections: Route Maintenance; Unit Maintenance; and Reports and Forms.The Route Maintenance section includes buttons for Route BaseInformation Maintenance, Pivot Plan Maintenance, Non-Delivery PointMaintenance, 3999 Data Capture/Summary, 3999 Data Transfer, DCDTransfer, 1838-C Data Capture/Special Office Mail Counts, and SpecialOffice Mail Counts Data Transfer. The Route Base Information Maintenanceallows the user to view and adjust information related to a route, forexample, travel times and begin times. The Pivot Plan Maintenance buttonthat allows the user to establish a pivot plan for a route, as discussedabove. The Non-Delivery Point Maintenance button allows a user tochange, for example, a route's park points, relay points, and collectionboxes. Park points are where a carrier parks his vehicle to make a loopon foot. A relay point is basically the same thing, where the carrierreturns to the vehicle between multiple loops. A collection box is wherecarriers pick up mail to be processed. The 3999 Data Capture/Summarybutton allows the user to modify the step-by-step travel pattern acarrier follows to deliver a route.

The 3999 Data Transfer window preferably allows the user to downloadinformation from a DCD that was used during a route inspection, streetmanagement, or a mail count. The 1838-C Data Capture/Special Office MailCounts button is used for a one-day office mail count for an individualcarrier. This information allows the system to determine the carrier'sdaily performance. The Special Office Mail Counts Data Transfer buttonallows the user to transfer the one-day office mail count for anindividual carrier into the application.

The Unit Maintenance tab is where the user identifies the delivery unit,its location, and gives general information about the delivery unit bypressing the Maintain Unit Information button. The Maintain CarrierRoute Assignments button allows the user to identify the carriers foreach route. The Maintain Dispatch Information button allows the user tointegrate an operating plan (a plan that the post office and the sortingfacility have to coordinate mail sent between the two facilities) andupdate information regarding when deliveries will arrive from a sortingfacility and how much mail will be in each delivery.

In one embodiment, the Reports and Forms section includes a number ofbuttons that perform the functions set forth below. Route BaseInformation Report button displays general information for all routes ina delivery unit. The Route Information Card button displays specificinformation about a route including reporting time, leave time, returntime, end time (carrier leaves the office to go home), and projectedmorning and evening mail volumes. The Route Performance Report buttondisplays carrier assignments and performance for a given period of time.The Unit Recap button displays assignments and performance for adelivery unit. The Delivery Point Sequence (“DPS”) Volume Impact Buttonallows the user to measure the impact the automated DPS sorter has onthe total number of letters the carrier has to sort, so that the savedtime can be subtracted from the carriers allowed sorting time. TheRoutes Pending Special Inspection button allows the user to display theroutes pending special inspection. The PS Form 3999 Inspection of aLetter Carrier Route button allows the user to get a history of thecarrier's performance. The 3999—Manual Entry button allows the user tomanually enter inspection information. The 1838 Carrier's Count of Mailbutton allows the user to print a one-day office mail count for anindividual carrier.

FIG. 58 illustrates an embodiment of a Route Base InformationMaintenance window, which provides information for a route that the userselects. The displayed information may include the type of route (e.g.,residential, business, mixed), the type of delivery (e.g., foot,dismount, curb line motorized, park and loop, etc.), and whether theroute is a full route or auxiliary, whether the route has Saturdaydelivery or not. This window may also display the route's begin time,leave time, return time, and end time on a daily basis, and the route'slast inspection date and statistics, and fixed office time (the amountof fixed office time that has been established for the route, which isnot driven by workload). This window may further display morning andevening mail volume information, percent-to-standard, and carrierinformation such as the regular carrier assigned to the route, his hiredate, date assign to the route, and the replacement carrier.

FIG. 59 illustrates an embodiment of a Pivot Plan Maintenance window,where the user can create a pivot plan and logical groups, as discussedabove, or assign route break locations. This takes the step-by-steptravel pattern a carrier follows to deliver a route and combine thatinformation with an interfacing Address Management System (“AMS”)database to identify the address of every delivery on a particular routeso that those deliveries can be split into logical groups. Once the usercreates logical groups of addresses, the system assigns an amount oftime for delivery, a travel pattern, a delivery method, possible pointsfor mail delivery (e.g., number of houses), the carrier's expected entertime and exit time for a particular logical group, and his firstdelivery. A block with no breaks is called a sector segment. Sectorsegments are already set up in the AMS database and are linked togetherby the user to create a logical group. In one embodiment, the systemreceives data from the AMS database weekly.

FIG. 60 illustrates an embodiment of a Define First Delivery Time windowthat allows a user to set the time when he expects the carrier to dropmail in the first delivery box on his route. FIG. 61 illustrates anAssign Route Proximity window, allowing the user to identify all of theroutes in close proximity to the route being pivoted. Assigning routeproximity helps the user reassign a section to another carrier having aproximate route and therefore lessen the time it takes the assistingcarrier to travel to assist with the route section. Assigning routeproximity is preferably only done once, but can be adjusted with thissame window.

FIG. 62 illustrates an embodiment of a Non-Delivery Point Maintenancewindow. Non-delivery points include park points, relay points, andcollection boxes. This window displays the location of non-deliverypoints for a route selected by the user. FIG. 63 illustrates anembodiment of a 3999 Data Capture Record Selection window. The userinputs a route number and the window displays the available 3999 formsthat were created to modify the step-by-step travel pattern a carrierfollows to deliver a route. The user can choose to edit any 3999 form oradd a new 3999 form.

FIG. 64 illustrates an embodiment of a 3999 Data Transfer window, asdiscussed above. The system lists all of the routes stored on themainframe, and the user can select certain of those routes to bedownloaded to the workstation. FIG. 65 illustrates an embodiment of a1838-C Data Capture and Maintenance window, allowing the user tomanually enter or edit mail volume information. The mail volume isbroken down by route and day, and identifies morning or evening volume.The window breaks mail volume down by type of mail. An optionalexpansion of the 1838-C Data Capture and Maintenance window can beprovided having fields for entering mail volumes.

The Unit Maintenance Menu feature can include a Unit Maintenance Menuwindow having buttons for the following functions: Maintain Unitinformation; Maintain Carrier Route Assignments; and Maintain DispatchInformation. FIG. 66 illustrates an embodiment of a Maintain UnitInformation window that appears when the corresponding button ispressed. This window includes the following sections: Unit Indicators(e.g., router, office break, and evening mail), Workload Status Setup,Capture Mail Volume Setup, and Regular and Miscellaneous RouteInformation. Workload Status setup allows the user to input whatthreshold of overtime and under time he wants to be alerted to. Forexample, if the user selects to view thirty minutes, only routes thathave 30 minutes or more of overtime or under time will be displayed.Capture Mail Volume Setup allows the user set thresholds for one or moretypes of mail. If the mail volume of a type of mail exceeds the enteredthreshold (which is entered as a percentage), the system highlights themail volume field to alert the user of a possible mistake. Thehighlighting may include turning the field yellow, bolding it, flashingit, or another method to draw the user's attention. Regular andMiscellaneous Route Information displays route base hours for the typeof route (regular or miscellaneous) chosen by the user.

In one embodiment, the system can include a window allowing the user toremove a route from a delivery unit. This might be done, for example,when a new ZIP code™ is created and routes are therefore moved to a newunit. FIG. 67 illustrates an embodiment of an Assign/Edit MiscellaneousRoute window that displays, for a given miscellaneous route number, itsZIP code™, type (e.g., collection route, relay route, or combinationroute), base hours, daily begin tour time and Saturday begin tour time.One or more confirmation windows may also appear asking the user toconfirm by selecting “Okay” prior to deleting a route from the system.

FIG. 68 illustrates an embodiment of a Maintain Carrier RouteAssignments window that lists all carriers, their type, and theirassignment. Carriers can be added, edited, or deleted. If the user isadding a carrier, the right side of this window allows him to enterinformation for that individual carrier.

FIG. 69 illustrates an embodiment of a Route Covered by T-6 window. Theuser inputs the ZIP code™ and route number, and can then assign a T-6 tothat route. FIG. 70 illustrates an embodiment of a Maintain DispatchInformation window allowing the user to display a list of dispatches(deliveries from the sorting facility, as discussed above), theirarrival time, and the percentage of the day's mail that is expected fromthe plant. FIG. 71 illustrates an embodiment of a Route Information Cardwindow allowing the user to display a chosen route and then printinformation about the route. FIG. 72 illustrates an embodiment of a UnitRecap window that displays what the delivery unit has done (e.g., aroute inspection, a minor adjustment, etc.) with routes over a period oftime, type of route, start date, end date, route status, and dateimplemented.

FIG. 73 illustrates an embodiment of a DPS Volume Impact window. Theuser selects a ZIP code™ to display, by route, the impact of having DPSsorted mail. FIG. 74 illustrates an embodiment of a Routes PendingSpecial Inspection window allowing the user to display routes pendinginspection for a particular week, or the user can schedule an inspectionby selecting a route number and a qualifying period end date. FIG. 75illustrates an embodiment of a 3999—Inspection of Letter Carrier Routewindow. The user identifies the route number and the data capture date,and can display inspection results. A Street Activity Start Time windowcan be provided for entering a start time for a particular route.

FIG. 76 illustrates an embodiment of a 3999 bata Capture/Summary window,allowing the user to manually enter route inspection information whichappears after the user selects the 3999—Manual Entry button. A MileageBreakdown window can be provided for inputting vehicle odometer readingsat various points in a carrier's workday, for example, when he reportsto the office, leaves the office, makes his first delivery, etc. duringan inspection period. FIG. 77 illustrates an embodiment of a Carrier'sCount of Mail window that displays a carrier's volume of mail for agiven date and route number during an inspection period.

In one embodiment of the present invention, the delivery operationsinformation system of the present invention includes a second module forRoute Inspections and Adjustments. FIG. 78 illustrates an embodiment ofa Route Inspections and Adjustments window. It is the first window thatopens in the second module. It displays whether the route adjustmentwill be formal, special, or minor. A special route adjustment request isone made by a carrier. In a minor route adjustment, the supervisor neednot accompany the carrier on the route but may instead use predeterminedcalculation to make the adjustment using the volume of mail and thehistorical time data for that route. The window displays start and enddates for the route adjustment. The user can press buttons to viewadjustment details, edit an adjustment, change the status of theadjustment from formal to minor to special, to define a new adjustment,to select an ongoing adjustment, or to change to view information for adifferent delivery facility (assists a user who supervises multipledelivery units).

FIG. 79 illustrates an embodiment of a Adjustment Details window thatyou get when you press the Adjustment Details button on the RouteInspections and Adjustments window. It identifies the route and thecarrier, along with the adjustment type, duration, and status(implemented or pending). FIG. 80 illustrates an embodiment of anAdjustment Comment Text window that is displayed when the user entersadjustment comments. This window allows the user to enter comments foran adjustment. FIG. 81 illustrates an embodiment of a Change Statuswindow that you get when you press the Change Status button on the RouteInspections and Adjustments window. It allows the user to change theadjustment status.

FIG. 82 illustrates an embodiment of a Define Adjustment window that youget when you press the Define New Adjustment button on the RouteInspections and Adjustments window. This is the user's first step increating a new adjustment to a route. The user first identifies the typeof adjustment (formal, special, or minor). If the user identifies formalor special, the Routes to Adjust section to the right accepts dataentry. In one embodiment, if the user identifies a minor adjustment, nodata can be entered in the Routes to Adjust section because there is nonormal inspection process associated with a minor adjustment. The userthen identifies a ZIP code™ and the routes in that ZIP code™ are listed.Once the user selects a route from that list, the system adds that routeto the Routes to Adjust section.

FIG. 83 illustrates an embodiment of a Select Adjustment window that youget when you press the Select Adjustment button on the Route Inspectionsand Adjustments window. This window gives the user a listing of theadjustments that are currently in the works, and the adjustment status(implemented or pending).

FIG. 84 illustrates an embodiment of a Route Inspection and AdjustmentsWorkbench window that is displayed when the user presses the Workbenchbutton from FIG. 78. Once an adjustment has been selected, the detailsof the adjustment are entered in this window. The window displaysinformation about the selected adjustment and has a Reports/Forms Menusection along with an Adjustment Functions section that includes fivesubsections: Advance Preparation; Analyze Data; conduct Inspection;Make/implement Adjustments; and Data Transfer. The Reports/Forms Menubutton allows the user to produce reports and forms related to a countinspection. The Advance Preparation subsection's Random TimecardAnalysis button allows a user to display a random time card analysisdata.

The Analyze Data subsection allows the user to analyze data such as DPSvolume impact, and to edit office time, select and edit street time, andadd or remove delivery points. The Conduct Inspection subsection allowsthe user to manually enter or edit mail volume information by pressingthe 1838-C Data Capture and Maintenance button (discussed above), modifythe step-by-step travel pattern a carrier follows to deliver a route bypressing the 3999 Data Capture/Summary button (discussed above), andrecord Examiner Observations and Comments after an inspection. TheMake/implement Adjustments subsection allows the user to createadjustment scenarios, maintain route base information once he hasidentified his desired scenario, and perform non-delivery pointmaintenance.

The Data Transfer subsection performs many electronic transfers andconfigures the user's workstation. Configuring the workstation involvesidentifying the delivery unit, the routes, etc. The user can perform a3999 Data Transfer after a route inspection, as discussed above.

FIG. 85 illustrates an embodiment of a Route Inspection and AdjustmentLaptop Workbench window. The laptop version of this window has many ofthe same features as the PC version of FIG. 84, but is not ascomprehensive.

FIG. 86 illustrates an embodiment of a Random Timecard Analysis—Summarywindow that can be accessed from the Advance Preparation subsection ofthe Route Inspections and Adjustments Workbench. Once the user has madethe random draw, the system displays the week number for the specificaccounting period and the week date. The system will also displaywhether that week was used and give the user the option to either go upor down a week. The system displays any “abnormal conditions” that wouldcause a user to go up or down a week to avoid any SPLY impact thatdistorted the data during that week. The system preferably performs anautomatic week adjustment such that, if the regular carrier was notworking his route on the chosen week, the system will skip to the nextweek. If the user wants to view any abnormalities during the chosenweeks, he presses the Abnormality Check button. If the list isacceptable to the user, he can press the Submit button and print anappropriate report.

FIG. 87 illustrates an embodiment of a Random Time Card Analysis Detailwindow that is displayed when the user presses the Analysis Detailbutton of the Random Timecard Analysis—Summary window. The user selectsthe route number and presses Display, and the system populates thefields of information from its own database. A Random Timecard Analysis(“RTA”) Comment window can be displayed when the user presses theComments button of the Random Timecard Analysis—Summary window,providing an empty text field for the user to enter comments andselecting “Okay” to save them into the system.

FIG. 88 illustrates an embodiment of an Examiner Observations andComments window that is displayed when the user presses the ExaminerObservations and Comments button in the Conduct Inspection subsection ofthe Route Inspections and Adjustments Workbench. The user selects aroute and the system, displays information including the examiner'scomments. The user can add new comments, and can select whether theinspection was performed in the office or on the street. A ViewObservations and Comments window can be displayed when the user pressesthe Preview Examiner Observations button from the Examiner Observationsand Comments window, providing an empty text field for the user to entercomments for a particular route.

FIG. 89 illustrates an embodiment of an Edit Office Time window that isdisplayed when the user presses the Edit Office Time button of theAnalyze Data subsection. The user selects a route number and the systemdisplays information about Line Items (e.g., includes breaks) from thecount and inspection, including the line item number, the standard time(time previously agreed to for performing certain functions), the day ofinspection (“DOI”), the after week of inspection (“AWOI”) time (timecarrier demonstrated he needed to perform those functions), and arepresentative time (what supervisor determines the carrier actuallyneeds). If the user changes any information displayed, he must enterjustification before saving.

FIG. 90 illustrates an embodiment of a Select/Edit Street Time windowthat is displayed when the user presses the Select/Edit Street Timebutton of the Analyze Data subsection. It has basically the samefeatures as the Edit Office Time window except that it displays timespent out of the office delivering mail. If the user changes anyinformation displayed, he must enter justification before saving.

FIG. 91 illustrates an embodiment of an Other Street Time windowallowing the user to enter information about a special activityoccurring on the street (e.g., a comfort stop) where the carrier leaveshis route. Accountable Delivery covers delays occurring when the carrieris delivering a piece of express mail and has to wait a long period oftime for the customer to come to the door. Other fields may includeParcel Delivery, Street Break Time, Collection Time, Deadhead Time (theamount of time it takes a carrier to walk from one delivery point toanother), Personal Needs (e.g., a comfort stop), Customer Contact, andGas Vehicle.

FIG. 92 illustrates an embodiment of a Non-Recurring Street Time windowallowing the user to enter information about a special activityoccurring on the street that the carrier should not be doing on a dailybasis. For example, Backtracking, Animal Interfere, Waiting for Relays,Waiting for Transportation, Waiting—Other, Accident, and Miscellaneous.Temporary Detail is when someone goes on a different route duringinspection. Management time is when the supervisor talks to the carrierwhile the carrier is delivering his route.

FIG. 93 illustrates an embodiment of a DPS Volume Impact window that isdisplayed when the user presses the DPS Volume Impact button of theAnalyze Data subsection. This window is also disclosed in FIG. 73 and isdiscussed above.

FIG. 94 illustrates an embodiment of an Add/Remove Delivery Pointswindow that is displayed when the user presses the Add/Remove DeliveryPoints button of the Analyze Data subsection. This window allows theuser to add and remove delivery points from a route. The systemautomatically calculates and displays changes to office time and streettime based on the addition or removal of the delivery point.

FIG. 95 illustrates an embodiment of an Add/Edit/Remove Non-DeliveryPoints window that is displayed when the user presses the Non-DeliveryPoint Maintenance button of the Make/implement Adjustments subsection.This window has two sections: Non-Delivery Point Attributes andNon-Delivery Point Sector Segment Association. The user sets thenon-delivery point attributes by selecting the non-delivery point type(e.g., collection point, relay box, park and loop point), the time thecarrier arrives at the non-delivery point daily, on Saturday, and onholidays. The user also inputs the possible deliveries per relay, loop,and swing, and a Location ID (for collection boxes having ID numbers).The user further inputs the Street Corner, Street Number, apre-directory designation (e.g., “North” for North Elm Street), StreetName, Suffix, etc. When the user presses the Display button in theNon-Delivery Point Sector Segment Association, the system breaks downthe sector segments and displays them.

FIG. 96 illustrates an embodiment of a Create Adjustment Scenarioswindow that is displayed when the user presses the Create AdjustmentScenarios button of the Make/Implement Adjustments subsection. Once theuser has performed a route inspection and has the associated data, hecan create certain scenarios to determine the most efficient route. Tocreate scenario 1, the user enters a ZIP code™ and each route withinthat ZIP code™ is displayed along with its office time, street time,allied time (time when the carrier is on the street but not deliveringmail (e.g., refilling mail between loops)), possible deliveries, andother factors. One example of a scenario is: what if I took thisparticular street off of one route and moved it to another route.

FIG. 97 illustrates an embodiment of a Make Adjustments window thatallows the user to adjust a scenario. The user can get to this screen,for example, by pressing the edit scenario button on FIG. 96. Thiswindow displays all of the time for a particular route and identifiesthe scenario being adjusted. The user can evaluate and adjust office,street, and allied time, and can assign a given amount of time to arouter. Street information is displayed by block range. New constructioncan be identified. In one embodiment of the invention, the user cansearch for a street by typing its name into the Find Street window. Theuser can move a block range from the route identified in the top Routefield to the Route identified in the bottom route field by highlightingthe desired block range and pressing the down arrow, and vice versa. Theinformation on the top will move to the bottom and the system willadjust the time fields accordingly.

FIG. 98 illustrates an embodiment of an Insert an Allied Time or SectorSegment window. This window allows the user to make a change to a routesuch as adding a collection box. This window also allows the user toidentify delivery zone changes (moving a route among delivery zones).

FIG. 99 illustrates an embodiment of an Allied Time window allowing theuser to adjust allied times. Relay Time is the time it takes a carrierto prepare for a relay at his vehicle. Travel To is the time it takesthe carrier to travel to and from lunch, to and from the route, etc.Vehicle Load is the time it takes the carrier to put his mail in hisvehicle. Vehicle Unload is the time it takes the carrier to unload hisvehicle.

FIG. 100 illustrates an embodiment of a Create New Route window thatallows the user to create a new route. The AMS database automaticallyprovides the new route number. After pressing OK, the user can makeadjustments to the new route.

FIG. 101 illustrates an embodiment of a New Construction window that isdisplayed when the user presses the New Construction button of FIG. 98.The user inputs when the construction began, when it is expected to end,location information, the anticipated number of deliveries to the newconstruction. The system uses a factor created from the route inspectionadjustment and determines the time the new construction will add to aroute. FIG. 102 illustrates an embodiment of an Adjustments In Scenariowindow that displays adjustments made to a scenario created by the user.A window can be displayed by the system to inform the user theworkstation is being configured.

FIG. 103 illustrates an embodiment of a DCD Transfer window that isdisplayed when the user presses the DCD Transfer button on the window ofFIG. 57 or FIG. 84. When the user is transferring information to andfrom a DCD, this window is displayed. The user selects the type of datatransfer (e.g., mail count or route inspections) and whether thetransfer is from the system of the invention to the DCD, or from the DCDto the system. The user also inputs the ZIP code™ and selects a routethat the transfer pertains to. When the user presses DCD Ready, thesystem performs the data transfer.

FIG. 104 illustrates an embodiment of a 1838-C/Examiner Observations andComments window that is displayed when the user presses the appropriatebutton in the Data Transfer subsection of the Route Inspections andAdjustments Workbench. The window displays route records on themainframe and the workstation and the user can press the appropriatebutton to transfer route data between the mainframe and the workstation.FIG. 105 illustrates an embodiment of a Transfer Data for a New 3999window that is displayed when the user presses the 3999 Data Transferbutton in the Data Transfer subsection. If the user has created a new3999, he identifies the route number that the system should transfer the3999 data to.

FIG. 106 illustrates an embodiment of a DRS Transfer window that isdisplayed when the user presses the DRS Transfer button in the DataTransfer subsection. Whether the user is importing DRS data to thesystem of the present inventions, or exporting it, the user inputs theZIP code™ and the file location. The Data Transfer Status window ispreferably displayed when the DRS data is transferring. The user cancancel the data transfer process from this window.

FIG. 107 illustrates an embodiment of a Reports and Forms window that isdisplayed when the user presses the Reports/Forms Menu button of FIG.85. The user can preferably print the following types of reports fromthis window: Route Performance; Route Inspection Summary; Unit Recap;Non-Delivery Point Changes; 52 Day implementation Plan (a calendar ofevents that must take place in order to meet contractual requirements);and Adjustment Analysis. In addition, the user can preferably print outthe following types of forms: 1838—Courier's Count of Mail;3999—Inspection of Letter Carrier Route; and 1840—Summary of Count andInspection.

FIG. 108 illustrates an embodiment of a Route Inspection Summary windowthat is displayed when the user presses the appropriate button on theReports and Forms window. The user selects whether he want a report of afull week or one day and then enters the date.

FIG. 109 illustrates an embodiment of a 1840 Auxiliary Assistancewindow. When, during an inspection, the user gets assistance to be ableto deliver his mail, that information is displayed here.

FIG. 110 illustrates an embodiment of a 1840—Summary of Count andInspection window that is displayed when the user presses theappropriate button on the Reports and Forms window. The user selects aroute number and can then also select a T-6 (replacement) carrier. If noreplacement carrier is selected, the system defaults to the regularcarrier. The user presses the button to display the form.

FIG. 111 illustrates an embodiment of a 1840 Reverse window that isdisplayed when the user presses the appropriate button on the Reportsand Forms window. The user enters the ZIP code™ and route, and alladjustments made to that route are displayed.

FIG. 112 illustrates an embodiment of a 3998—Unit Summary window that isdisplayed when the user presses the appropriate button on the Reportsand Forms window. The user inputs a delivery unit and presses the buttonto display a summary of adjustments made for the entire unit.

FIG. 113 illustrates an embodiment of a System Administration Workbenchwindow that is displayed when certain types of users log on. This windowhas buttons for maintaining user profiles, maintaining districtorganizations, and maintaining 52-day implementation plans. The systemincludes several different levels of access to these functions. The usermust be mapped to a particular level to perform them.

FIG. 114 illustrates an embodiment of a Maintain User Profile windowthat is displayed when the user presses the appropriate button on theReports and Forms window. The user identifies, for a given ID and username, the user's primary delivery unit and class (e.g., supervisor,manager, system administrator, etc.).

FIG. 115 illustrates an embodiment of a New Profile Item window. Thiswindow allows the user to create a new profile for a user or a new userclass (e.g., supervisor, manager, route inspector, etc.) and thedelivery unit for that particular user class.

FIG. 116 illustrates an embodiment of a Maintain District Organizationwindow where the district organization is displayed in a tree format.This window allows the user to view, edit, reassign, delete, and add tothe district, its facilities, and its management areas.

FIG. 117 illustrates an embodiment of a Post Office Operation AreaDetails window that is displayed when the user presses the appropriatebutton from the Maintain District Organization window to add a new postoffice operation area. The user selects the name of the post office thathe will be adding. FIG. 118 illustrates an embodiment of a InstallationDetails window that is displayed when the user presses the appropriatebutton from the Maintain District Organization window to add a newinstallation. The user assigns a finance number, city, and state to thenew installation. An installation can consist of an individual building,or it can consist of multiple facilities.

FIG. 119 illustrates an embodiment of a Facility Detail window that isdisplayed when the user presses the appropriate button from the MaintainDistrict Organization window to add a new facility. The user enterscertain information about the facility. FIG. 120 illustrates anembodiment of a Delivery Unit Detail window that is displayed when theuser presses the appropriate button from the Maintain DistrictOrganization window to add a new delivery unit.

FIG. 121 illustrates an embodiment of an Assign Existing ZIP Code™window that is displayed when the user presses the appropriate buttonfrom the Maintain District Organization window to add an existing ZIPcode™. FIG. 122 illustrates an embodiment of a Maintain 52 DayImplementation Plan window that allows a user to add an activity to his52-day plan. The user can get to this screen by pressing the appropriatebutton on the System Administration Workbench window discussed above.

FIG. 123 illustrates an embodiment of a Data Preparation Workbenchwindow. The window preferably has three tabs: Workload, Workforce, andInterfaces. This screen allows the user to activate a delivery unit byinputting the delivery unit's initial base data. The Workload tabpreferably includes a Delivery Unit and a City Delivery Routes sections.The Delivery Unit section preferably includes buttons for DataPreparation Setup, Enter Unit Characteristics, Enter Unit DispatchSchedule, and Enter Unit Annual Budget. The City Delivery Routes sectionpreferably includes buttons for Enter Route Base Information, Enter NonDelivery Point Data, Enter Previous 3999 (the step-by-step travelpattern a carrier follows to deliver a route), 3999 Record Transfer,Enter Pivot Plan Data, and Enter Unit Miscellaneous Route Details.

FIG. 124 illustrates an embodiment of a New Delivery Unit window thatcan be accessed from the Maintain District Organization Window. In thiswindow, the user identifies the new delivery units area ID, district ID,facility ID, group ID, and assigned finance number. This informationlinks delivery units to other units and facilities within their district(see FIG. 116).

In one embodiment of the invention, data is gathered for creating a newdelivery unit by pulling in data from the AMS database and otherinterfacing databases that have relevant information about routes, etc.

FIG. 125 illustrates an embodiment of a Generate Weekly Schedule windowthat allows the user to generate a weekly schedule for a delivery unitby inputting a service week start date. The user accesses this screenfrom the Workforce tab of the Data Preparation Workbench.

FIG. 126 illustrates another facet of the present invention. It is a webpage that can be viewed online that allows users of the deliveryoperations information system of the present invention to view thesystem status. In one embodiment, the web page informs the user of thesystem's availability. For example, the user can be informed that thesystem is fully functional, slow, or unavailable. This can be achieved,for example, by the web page sending a communication to the deliveryoperations information system and tracking whether and when the systemto returns a communication. By refreshing the web page, the systemstatus is updated. In the illustrated embodiment, the availabilitydetermination is accompanied by an easily viewable symbol of trafficsignal that is green when the system is fully functional, yellow whenthe system is slow, and red when the system is unavailable. This webpage can provide additional online support for the user, such as a “Tipof the Day” or the ability to reset system passwords or view certaininformation online.

In one embodiment, the delivery operations information system of thepresent invention can also provide a function for adjusting a carrier'sweekly schedule. From the office function, a Weekly Schedule window canbe open. By right clicking on a selected field, the user can select froma number of different functions, such as: Quick Assign, AssignmentDetails, Create Vacancy, and Show. For each of these options, the usercan select from: Regular Routes, Miscellaneous Routes, Carrier WorkStatus, Absence List, Sunday, or Vacant Routes. The Weekly Schedulewindow can allow a user to insert a replacement carrier, as shown inFIG. 127. The Weekly Schedule window can also show absence status, asshown in FIG. 128. Of course, it is also possible to view regular routesof carriers in the Weekly Schedule window, as shown in FIG. 129. Fromthis window, it is also possible for a user to assign a replacementcarrier. For example, FIG. 130 shows a Weekly Schedule window in whichthe user can also view the Route Daily Details window and the AssignReplacement window.

Turning back to the Maintain District Organization function, in anexemplary embodiment the system can allow the user to share ZIP codes™across one or more facilities. FIG. 131 illustrates an embodiment of aMaintain District Organization window including this feature. After theuser presses the Add Existing 5 Digit ZIP Code™ button, the user ispresented with a window called Assign Existing ZIP Code™ into which hecan enter the new code for a selected facility or location. This featureenables the new ZIP code™ to be shared across facility or installationboundaries. Thus, multiple ZIP codes™ can be assigned to a singledelivery facility.

FIG. 132 illustrates an embodiment of a window that is presented to theuser after selecting the New Installation button from the MaintainDistrict Organization window. This window displays the finance numbersfor the installations or facilities and the facility name in theInstallation Name field. After entering the appropriate finance number,the display can appear in a tree format with the finance numberfollowing the name of the installation or delivery facility name.

With the present features of the system, the user is able to reassign adelivery facility without having to change the Facility Name field.Further, it is possible to sort alphabetically the installation orfacility names, as the drop down lists are based on installation namesor facility names. Also, by displaying the finance number forinstallation and facilities on the Maintain District Organizationscreen, it is easier for the user to gather station data based onfinance number.

The preferred embodiment is configured to make the process of changinginstallation names easier. FIG. 133 illustrates an embodiment of awindow that is presented to the user after selecting an installationfrom the tree chart off the Maintain District Organization window andhitting the Edit button. The Edit Installation window includes fieldsfor Finance Number, City, State, and Installation Name. For example, ifthe Installation Name is the same as the City which is shown in thefield, then the user can delete the entry in the Installation Name fieldand simply correct the entry for the City field. By hitting the tabbutton, the Installation Name field will automatically be filled out toreflect the change to the City field. The auto-populate field feature ofthe present system, as exemplified here, reduces the number ofkeystrokes and the possibility of typographical errors. In addition, thesystem will recognize the change to the City field and change theFinance Number field accordingly. On the Maintain District Organizationscreen, the installation now reflects the new finance number, though thefacility does not. If the user closes the Maintain District Organizationscreen and then reopens it, the facility now shows the changed financenumber. If the user were to highlight the facility and hit the Editbutton, a window such as shown in FIG. 134 would appear that allows theuser to be able to edit the station or facility information on the EditFacility window, but not the finance number.

FIG. 135 illustrates a Supervisor Workbench screen of another exemplaryembodiment of the present invention. The Supervisor Workbench has aseries of tabs across the top to separate each individual section. Thesections may include, for example: Daily Workload Management; StreetManagement; Performance Reports; Planning Scheduling; and Route and UnitMaintenance. The Performance Reports tab is chosen and displayed in FIG.136. This tab also includes the function button entitled Steward,Standby, and Meeting Time Report under the section Unit PerformanceReports. Selecting this button presents the user with a Steward,Standby, Meeting Report window similar to the one shown in FIG. 137. Theuser can enter the start date of the service week, and by selecting thePrint Preview button, is able to generate a report for that week whichprovides the details of each of the types of time (e.g., steward,standby, and meeting) by operation code for the particular delivery unitof interest.

A report displaying steward, standby and meeting time that can begenerated using the system of the present invention. A user can generatethis report by selecting the Unit Feedback Report button from thePerformance Report tab from the Supervisor Workbench. The report caninclude information about a deliver unit's identity (ID), the begindate, end date, and service week, the carrier's name and route ID, thetype of carrier (e.g., part time, full time), the dates with beginningand end times telling exactly when time was recorded for steward,standby or meeting times, the duration of the time for each instancewhere steward, standby or meeting time was recorded, and the totalweekly durations for the various types of time. This information can bedisplayed separately by the type of time that is being recorded. Such areport can be generated for a unit by either the route or by thecarrier. For example, the Steward, Standby and Meeting Time Reportwindow can allow the user to select a report based on route or bycarrier, as shown in FIG. 137.

Steward, standby and meeting times are a subset of the general officetime that is being monitored. Tracking the steward, standby and meetingtimes can provide delivery unit supervisors with more information on howoffice time is being used. Hence, the display of steward, standby andmeeting time can assist supervisors in their ability to effectively andefficiently manage delivery units. For example, where a delivery truckis delayed in getting to the receiving dock and the receiving dockemployee has some down time before the truck arrives, this down time canbe captured in the system. If that employee's manager has a discussionwith the receiving dock employee, that time can be captured as meetingtime. Then, by preparing the report the supervisor can determine how thetotal work time has been spent.

Another useful feature of the system is the ability to generate a UnitFeedback Report from the Supervisor Workbench. The Unit Feedback Reportallows users to view the previous day's overall performance for adelivery unit. This daily performance/analysis report outlines thefollowing: usage, quality practices, and effectiveness data.

The usage section of the report allows users to track how their deliveryunits are using the main functions of the system, including logon,capture of mail volumes (manual and with data collection device), EORtransfer, and application version. The quality practices section allowsusers to track how they are managing quality practices of the system.These quality practices can include, for example, timeliness of reports,allocation of miscellaneous time, daily statistics, a summary of thesteward, standby and meeting times, and additional miscellaneous times.The effectiveness data can include effectiveness indicators such asovertime percentage, adjusted office effectiveness, adjusted streeteffectiveness, and adjusted workload effectiveness.

The Performance Report tab of the Supervisor Workbench window of FIG.132 can also include a Unit Daily Performance Report button which, whenselected, can generate a daily performance report for a select unit.This report lists daily performance information over the course of oneweek for a delivery unit. The report can include several sections ofinterest, such as work hour analysis and productivity analysis. The workhour analysis and the productivity analysis can be displayed by dailysection and/or weekly section. The report can include a sectionsummarizing breakdown of mail volumes for select types of deliverablearticles, such as letters, flats, DPS, delayed, curtailed, sequenced,and parcel and priority articles.

The unit daily performance report can also include information such as acomparison of actual deliveries to budget, as well as a percent variancefor possible deliveries. Also included with the report is an analysis ofthe unit's work hours. These can include projected and actual values forthe office, street, and route times; and variances and percent variancesfor office and street times, including router time. In addition, thereport can include a comparison of LDC's 21, 22 and 29 projected, actualand budgeted hours, and total and budgeted variance hours.

The report can also include an analysis of productivity indicators forthe office and for the street. The office efficiency indicator (OEI)designates the average amount of time spent in the office on eachpossible delivery in the unit. The adjusted office effectivenessindicator (OE) designates how the unit performed versus projected officetime. The total efficiency indicator (TEI) designates the overallefficiency of the unit. The workload effectiveness (WE) designates theoverall effectiveness of the unit. All of the efficiency indicators(OEI, OE, TEI, WE) can be adjusted for steward, standby and meetingtimes. The report can be broken down to display OEI and adjusted OEI, aswell as effectiveness (OE) calculations, for AM and PM office data.

Further, the report can include an AM/PM breakdown of office and routertime, including miscellaneous time such as steward, standby and meetingtimes. The report can also include a weekly totals section containing asummary of the figures for the week to date.

FIG. 138 illustrates a diagram of an exemplary mail delivery process forwhich the present system can be utilized to capture and recordinformation relating to the delivery. From this information, the UnitDaily Performance report can be prepared.

The delivery operations information system (DOIS) of the presentinvention can also be integrated with a change of address request system(COARS) in order to provide maximum flexibility to the user of thesystem. Using DOIS, it can be possible to validate user access torequested ZIP codes™. As shown in FIG. 139, in one exemplary embodimentthe Maintain User Profile window can include a list of profiles, whichcan include a number of COARS user classes, such as COARS Area User,COARS Computerized Forward System (CFS) Supervisor, COARS ConsumerAffairs, COARS District User, COARS Super User, and COARS UnitSupervisor. Only valid combinations of primary and secondary profilescan be accepted to gain access to the system. This security featureensures that only certain authorized users can gain access to determinewhere a particular customer has moved or is now residing.

In another exemplary embodiment, the DOIS can also be integrated to thefacility data base (FDB), so that a link is created between the DOISfacility database and the FDB facility database. In this way, it ispossible to generate reports to help manage DOIS facility data againstFDB facility data. Thus, a DOIS user can gather information on aparticular facility, such as the street address, the number of doorsavailable to accept delivery trucks, whether it has a gate, runs on gasor electric, etc. The information between both databases is thus sharedso that congruency between the databases can be maintained.

In one exemplary embodiment, a user can access the facility detail byselecting an installation from the tree chart of the Maintain DistrictOrganization window and hitting the Edit button. As previouslydiscussed, the Maintain District Organization window can be accessedthrough the System Administration Workbench. In the Edit Facility Detailwindow, the user will be presented with a series of warning messages.The values coming from the DOIS database are validated before the windowis opened. FIG. 140 illustrates an exemplary Edit Facility detail windowthat opens after the user has accepted the last warning message. Asshown, the window includes both the existing DOIS facility data as wellas an area for FDB information. A Browse FDB button is also provided inthis window. By selecting the Browse FDB button, the user can comparethe finance number of the facility with the finance numbers listed inthe Facility Selection window of the FDB database that pops up. Once inthe Facility Selection window, the user can select a particular facilityfrom the FDB grid (FIG. 141). If the user selects an inactive facility,the system will show a warning message and ask the user if he or shewishes to proceed. After this message, the system displays the EditFacility window with the DOIS information and the updated FDBinformation. The user can save the link between the FDB and DOISdatabases by selecting the OK button from the Edit Facility window (FIG.142). To abort the changes, the user would select the Cancel buttoninstead.

If the user wishes to add a new facility to the DOIS database andinclude FDB information, he or she would select an installation from thetree chart of the Maintain District Organization window and select theAdd New Facility button. A New Facility window would then open, with thefinance number from the selected installation filled in. After the userenters the appropriate information for the Type, City, State, ZIP Code™,and Name fields, he or she can select the OK button to create a newfacility record. This facility record will be saved in the DOISdatabase, without a link to the FDB database. To complete the newlycreated record, the user would repeat the above-discussed steps.

It is also possible to generate district reports with FDB and DOISdatabase information using the present system. As shown in FIG. 143, theuser can select the District Report button from the System AdministratorWorkbench window. The user would then be presented with the DistrictReport window, from which he or she can select District Facilitieswithout FDB Facility IDs or DOIS Variance Report buttons (FIG. 144).Selecting the District Facilities without FDB Facility IDs button wouldgenerate a district report for facilities without FDB facility ID, whileselecting the DOIS Variance Report button would generate a districtreport for FDB variances whereby any difference in finance number,state, ZIP code™, sub type, or status would result in an entry on thatreport. These report would thus enable the user to maintain datacongruency between the DOIS and FSB databases.

Additionally, in an exemplary embodiment the system of the presentinvention can provide a function that tracks an office's compliance withthe AM Standard Operating Procedures (AM SOP). From the data gathered,AM SOP certification team members will have the ability to edit and viewthe AM SOP certification status of DOIS. This function can be accessedby selecting the AM SOP Certification Status button from the SystemAdministration Workbench window, as shown in FIG. 145. By selecting thisbutton, AM SOP team members will be able to access, edit and view AM SOPcertification status information for DOIS sites. FIG. 146 illustrates anAM Standard Operating Procedures Certification Status window. Thiswindow allows the team members to record and view the certificationstatus of an office. As shown, components such as the following can betracked: date the AM SOP certification was completed; TOP audit resultsin the delivery section; TOP audit results overall; date the IOP wasimplemented; date the case configuration was completed; date the unitlayout was approved; date the carrier schedule was approved; date thearea review was conducted; and unit pass review results.

Upon entering the AM SOP window for the first time, the user may noticethat the date fields are empty. After the user selects the type ofcertification status desired by checking the box next to the entry type(e.g., IOP, Case Configuration, Unit Layout, or Carrier Schedule), thenthe date field associated with that certification type can be populatedwith the current date or the date last entered in the system for thatcertification. An empty date field would indicate that the milestone orcertification was not yet complete for that item. A user could changethe date if needed by using the up and down arrows in the box next tothe date field, or by manually entering the numbers. Selecting the Savebutton would save the information while selecting the Close button wouldclose the window and discard any changes that were made. Once the AM SOPinformation has been recorded for a unit, the changes would appear uponentering the AM SOP window. Users would have the ability to revise theAM SOP information for any particular unit.

In yet another exemplary embodiment, the system can include a functionto record volumes of mail (letters and flats) by trip. The methodincludes the ability to track the actual receipts of mail and to be ableto track the volumes (letters and flats) by dispatch compared to theIOP. In one example, the method would require a supervisor to enter thesource of the mail and arrival time prior to saving mail volumes. PMdispatches would also be recorded similar to AM dispatches. Further,miscellaneous route volumes would also be recorded. The method wouldalso allow the recording of unit distribution, P.O. box, and rural routevolumes for the delivery unit. With this function, DOIS would be able tocalculate what time mail arrives at the carrier's cases, and be able toidentify the time a carrier has, for example, 80% of their AM caseablemail and, for example, 100% of their flats for the day.

FIG. 147 illustrates a Capture Mail Volume window adjacent to a WorkloadStatus window of one embodiment of the present invention. The WorkloadStatus window shows the route, carrier, and the amount of time thatcarrier was over or under the expected time. The Capture MailVolume—Manual window shows a list of the routes and the total volume ofmail for those routes. By viewing the two windows side by side, a useris able to make business decisions based on the data shown in thedisplays.

FIGS. 148 and 149 illustrate a Capture Mail Volumes—Manual window ofanother embodiment of the present invention, for withdrawal and roll-insources, respectively. As shown in FIG. 148, if withdrawal is chosen asa source, then the arrival time is recorded prior to saving theinformation. If roll-in is the source chosen, as in FIG. 149, then thedisplay button shows a roll-in button instead. This feature enables thesystem to record a time at which the volume of mail changes at thecarriers' cases.

FIGS. 150 and 151 illustrate a PM Available window and a PM Curtailedwindow, both of which are accessed through the Capture MailVolume—Manual window. After choosing the date, the PM Available categoryfield, and the Units field, the Display button can be enabled, showing awindow similar to FIG. 150. If the user chooses the date, the categoryPM Curtailed in the category field, and the Units field, then a windowsimilar to the one shown in FIG. 151 will appear after selecting theDisplay button. These windows allow for the addition of recordingdispatches, unit distributions, and automated caseable letters andautomated caseable flats for PM dispatch arrivals.

FIG. 152 illustrates an embodiment of a Capture Mail Volumes—DCD window.As shown, the user is asked to enter an arrival time for any withdrawal,thereby allowing the system to record a time at which the volume of mailchanges at the carrier's case. The Transfer Volume Data button isenabled after the user enters a withdrawal time. Of course, the CaptureMail Volumes can also be manually entered, as previously discussed. Forexample, Capture Mail Volumes—Manual windows can be provided allowingthe user to select the date, the category of route (i.e., rural, PO Box,or miscellaneous), and the units of mail volume field. FIG. 153illustrates such a window for a rural route. These windows enable theuser to enter mail volumes specific to these types of routes, therebyproviding a system that can capture more detailed information relatingto the carrier's route.

FIG. 154 illustrates a Maintain Dispatch Information window of thepresent embodiment, which can include columns for AM Dispatch, ArrivalTime, Automated Letters, and Automated Flats. This information tells theuser if the Dispatch trip is scheduled for the morning.

From the Capture Mail Volume window, a user can click on a route andaccess a Detailed Route Volume window similar to that shown in FIG. 155.This window can display the details of how the mail volumes wererecorded for the day. The user can edit this screen, which would updatethe mail volumes for the day. If the user wishes to record or adjust adispatch, he or she could use the Capture Daily Dispatch Informationwindow, similar to the one shown in FIG. 156. From this window, the usercan record a dispatch by pressing the Record Dispatch Trip button. ARecord Dispatch Trip window similar to the one shown in FIG. 157 wouldappear, allowing the user to enter the details about the trip that hasarrived. The information would then be displayed on the Capture DailyDispatch Information window after the user selects the Save button.

With this capture volume feature of the present embodiment of theinvention, a user is also able to generate several reports with thecaptured data. For example, it is possible to generate a Volume FeedbackReport by selecting that button. The report can be based on routedetail, unit, or unit distribution. In the Unit Daily PerformanceReport, the Mail Volumes section can be broken down to include unitdistribution of letters, flats, and parcels. The P.O. box entry would bebroken down to include letters, flats, and parcels, and rural routeswould include subcategories of DPS, letters, flats and parcels. Thisinformation can be displayed in a Mail Volume section of a unit dailyperformance report. A Unit Distribution Volume Feedback Report can alsobe generated using the present system to display unit distributionletters, flats, and parcels by day, including weekly totals for theselected unit. A representative Unit Distribution Volume Feedback Reportis shown in FIG. 158.

Another report that can be generated is the Unit Volume Feedback Report,which can display the time when, for example, 80% of the carrier's mailto be cased is available for a selected week for all routes in theselected unit. The report can also display the time when, for example,100% of the carriers flats to be cased are available for a selectedweek. A summary can be provided which would represent the totals fornon-compliance, unscheduled trips and to the unit, and number of tripsthat were at least a certain time, such as 15 minutes, late, for theselected unit. A representative Unit Volume Feedback Report isillustrated in FIG. 159.

A Route Detail Volume Report can also be generated using the presentsystem. The Route Detail Volume Report can display the time that, forexample, 80% of the carriers' mail to be cased is available and when,for example, 100% of the carriers' flats to be cased are available. Thereport can provide a detailed view of roll-ins, dispatch trips andwithdrawals for a route in one day. A representative Route Detail VolumeReport is illustrated in FIG. 160.

FIG. 161 illustrates one embodiment of the Route Adjustment Systemfunction of the DOIS. The route adjustment system is a tool that can beprovided to help supervisors determine the value of a particular route.The route adjustment system also allows supervisors to be able tomaintain a carrier's route time as close to 8 hours as possible. Thesystem involves evaluation of the route at both the office and thestreet level. Data such as time allocation from both levels is collectedand entered into the system, where the supervisor can analyze the datato detect inefficiencies and make determinations on how to improve andmaintain an efficient route and carrier workforce.

FIG. 161 illustrates a route details window of the Route AdjustmentSystem of the present invention. All options for adjusting (approving)projections are available from the Workload Management menu. Selectingthe Accountables Over Base option opens the Projection Adjustmentwindow. Under Mail Volume, a user can click the Curtail or Delay Mailbutton and this would open the Save Mail Volume Manual Window. Byhighlight a row under Description, a user can click the AdjustProjection button and this would open the Project Adjustment window forthat selected row. Further, the user can save any changes or entriesafter the requested time is adjusted. By “total projected time” what ismeant is the sum of all the projected time for this route. This time canbe used in the calculation of the “approved route time,” which iscalculated based on a regular route time (projected at eight hours) andany auxiliary route time.

The Approval or Disapproval buttons, as well as the Save and Cancel areenabled only after the requested time has been adjusted. When theDisapproved check button is checked a Comments box can be visible andenabled. In one embodiment, the Comments field is always required if theDisapproval box is checked.

FIG. 162 illustrates an exemplary Route Projection Adjustment windowprovided by the present invention. This window allows a user to adjustthe standard street projection for a particular route, and to entercomments for the reason for the adjustment, such as for exampleconstruction deviation as shown in FIG. 163. FIG. 164 illustrates anAssignment Details window which allows a user to adjust an office timeof a route. FIGS. 163 and 164 illustrate particular Assignment Detailswindows that appear when the assignment type is an AM Office Auxiliaryor a Street Auxiliary. The AM Office Auxiliary assignment type may alsolead the user to a Scheduled Carrier List window, as previouslydescribed, while the Street Auxiliary assignment type may further leadthe user to pivot options similar to the features in the Pivot Routemenu from the Supervisor's Workbench.

FIG. 165 illustrates an exemplary Maintain Unit Information window. Asshown, the window includes a Projection Adjustment Set-Up button thatwould allow the user to open a Unit Projection Adjustment Set-Up windowsimilar to the one shown in FIG. 166. By providing an automatedinclusion feature, a district administrator can automatically includeany of the projection adjustments for all of the routes in a deliveryunit, on a daily basis. The supervisor would not be required to manuallyapprove each projection for every route, as some would be automaticallyrecognized or approved. The supervisor would have the option to removeor adjust any projection adjustments on a daily basis to reflect currentworkloads through the Route Details window, however. Further, the systemis configured such that a supervisor can retroactively enter adjustmentsfor previously worked days. This option is beneficial where a supervisorhas made, for example, an oral adjustment the previous day and did notenter that adjustment into the system due to time constraints or simplyforgot to do so. By allowing the supervisor to retroactively record thatadjustment into the system, a more accurate report and accounting can bemade of the actual work performed for any given day or period.

Preferably, each of the system's windows has a help button. The helpbutton is window-sensitive and includes extensive online help, includinga brief description of the purpose of the window.

This delivery operation information system of the present invention canbe used for both city letter carriers and rural carriers. The embodimentof the system described above is tailored to city carriers, but could beused, preferably with appropriate alterations, for rural carriers. Thesystem may also include an automatic budgeting feature allowing the userto tap into a national budget system for local downloads or data.

The system of the present invention can include several securityfeatures to prevent unauthorized access to the system and also toprotect the privacy of the identities within the system's database. Forexample, it is understood that access to the system of the presentinvention can be controlled by granting selective access to authorizedusers only. For example, the Unit Feedback Report can be available tousers with Manager access and Managers with National User access. Also,the system can be configured so that reports, such as for example the PSForm 3999, which include a carrier's ID number (usually the carrier'ssocial security number) masks the first five characters and identifiesonly the last four digits of that ID number. Further, the system isconfigured to allow only users with a recognized profile to log on. If auser tries to log on to the system, and he or she does not have arecognized profile or the profile information is incorrect (i.e., noaccess to that level of the system), then a DOIS warning window similarto the one shown in FIG. 202 will appear. This DOIS window notifies theuser that he or she must contact a DOIS coordinator to set up a userprofile before proceeding further. Upon hitting the OK button, theapplication closes and prevents further access of the system by theunauthorized user.

In an exemplary embodiment, the Managed Service Points and StreetManagement System 380 can be divided into two subcomponents: ManagedService Points Maintenance and Managed Service Points PerformanceReports. From the Managed Service Points Maintenance menu, a user canaccess features such as MSP Base Information Maintenance, MSP LocationReport, MSP Label Request Status, and MSP Conversion. From the ManagedService Points Performance Reports menu, a user can access reports suchas an MSP Overview Report, MSP Route Report, MSP Carrier Report, MissedScan Report, Invalid Route Report, and Invalid Scan Report.

In one embodiment, the Route Inspections and Adjustments Workbenchwindow can include an MSP Base Information Maintenance window in theMake/Implement Adjustments frame. The window allows route inspectors tomaintain MSPs during a route inspection. Additionally, the SystemAdministration Workbench can include a button for an MSP Label RequestStatus window. This window enables system administrators to print,reject, request, or view the status of MSP barcode labels for thedistrict. The MSP Base Information Maintenance window allows MSPs to beadded, edited, and deleted from a DOIS route. The base informationdisplayed includes the MSP Type, Address, Label Location, Scheduled ScanTime, Scheduled Interval, and a Saturday Non-Delivery Indicator. The MSPLabel Request window is also accessible via this window. The MSP LabelRequest window allows users to request Office, Street, and MailingLabels from system administration. System administrators can makerequests for every facility in the district, whereas, delivery unitsupervisors can only request labels for their unit. The labelinformation displayed on the window includes the Delivery Unit, RouteNumber, MSP Type, Address, Label Location, Number of Labels PreviouslyRequested, and a New MSP Indicator.

The MSP Label Request window can be accessible via the MSP Label RequestStatus window or the MSP Base Information Maintenance window. Bothwindows are located on the Street Management Tab of the SupervisorWorkbench. The MSP Label Request Status window can also be accessed fromthe System Administration Workbench.

The System Administration Workbench, as well as the Street Managementtab on the Supervisor Workbench, can also include an MSP Label RequestStatus window. The MSP Label Request Status window allows users to viewthe status of existing label requests. System administrators can viewthe status of all label requests in the district, and delivery unitsupervisors can view the status of all label requests in the unit.Labels can have a status of Submitted, Printed, or Rejected. From thiswindow, users also have access to the MSP Label Request window.

The MSP Print Label window can be accessed via the MSP Label RequestStatus window, if opened from the System Administration Workbench. TheMSP Print Label window allows system administrators the ability to printrequested labels. The user will first display the outstanding labelrequests. The information displayed for each label request includes:Delivery Unit, Route Number, MSP Type, Address, Label Location, DateRequested, Number of Labels Previously Requested, New MSP Indicator, andStatus. Once the label requests are displayed, the user can select thelabels to print or reject. If a label is being rejected, a comment mustbe entered describing the reason for rejection.

Also accessible from the Street Management tab on the SupervisorWorkbench is an MSP Location Report function. This new MSP maintenancereport displays MSP base information for a selected route. The reportoutlines the following for each route in the delivery unit: RegularCarrier, MSP Type, Address, Label Location, Scheduled Scan Time, andScheduled Interval.

The present system can also generate an MSP Overview Report. This newreport displays MSP performance data for an entire delivery unit. Thefollowing fields are displayed for each route in the delivery unit:Assigned Carrier, Actual On-Time Scan Percentage, Load Time (Scheduled,Actual, and Variance), Travel To Time (Scheduled, Actual, and Variance),Travel From Time (Scheduled, Actual, and Variance), Total Street Time(Scheduled, Actual, and Variance), and Keyed Entry Indicator. DeliveryUnit Totals are also displayed for each of the above fields. Users cangenerate a Daily or a Weekly Summary of the report. If a Weekly Summaryis generated, the report will display route and unit averages, insteadof actuals, for each of the displayed fields. The MSP Overview Reportcan be viewed/printed the following day after MSP performanceinformation has been uploaded into DOIS. It is accessible from theStreet Management tab on the Supervisor Workbench.

Another report that can be generated using the present system is an MSPRoute Report. This new report displays MSP performance data for one orall routes in a delivery unit. The following fields are displayed foreach route: MSP Type, Address, Assigned Carrier, Scan Time (Scheduled,Actual, and Variance), and Keyed Entry Indicator. Users can generate aDaily or a Weekly Summary of the report. If a Weekly Summary isgenerated, the report will display the Average Scan Time, instead of theActual Scan Time. The MSP Route Report can be viewed/printed thefollowing day after MSP performance information has been uploaded intoDOIS. It is accessible from the Street Management tab on the SupervisorWorkbench.

Yet anther report that can be generated is an MSP Carrier Report. Thisnew report displays MSP performance data for one or all carriers in adelivery unit. The following fields are displayed for each carrier:Route Number, MSP Type, Address, Scan Time (Adjusted Scheduled,Scheduled, Actual, and Variance to Scheduled), Scan Interval (AdjustedScheduled, Actual, and Variance to Adjusted Scheduled), and Keyed EntryIndicator. The MSP Carrier Report can be viewed/printed the followingday after MSP performance information has been uploaded into DOIS andcan be generated for a single service date. It is accessible from theStreet Management tab on the Supervisor Workbench.

The system can also generate a Missed Scan Report. This new reportdisplays missed scan statistics for each route in the delivery unit. Thefollowing fields are displayed for each route: Assigned Carrier,Possible Office Scans, Actual Office Scans, Office Scan Percentage,Possible Street Scans, Actual Street Scans, and Street Scan Percentage.Delivery Unit Totals are also displayed for each of the above fields.The Missed Scan Report can be viewed/printed the following day after MSPperformance information has been uploaded into DOIS. It can be generatedfor a service date or for a service week. The report is accessible fromthe Street Management tab on the Supervisor Workbench.

Another report that can be generated with the present system is anInvalid Route Report. The Invalid Route Report identifies the carriersin the delivery unit that have logged into the Mobile Data CollectionDevice (MDCD) using an invalid route number. An invalid route number isdefined as one that is not recognized by DOIS. The report displays thefollowing fields for each invalid route: Carrier Name, Invalid RouteNumber, DOIS Assigned Route Number, and Hot Case Route Number. TheInvalid Route Report can be viewed/printed the following day after MSPperformance information has been uploaded into DOIS and can be generatedfor a single service date. It is accessible from the Street Managementtab on the Supervisor Workbench.

Still a further report that can be generated is an Invalid Scan Report.This new report displays MSP performance data for each invalid scanduring the selected service date. The following fields are displayed onthe report: Route Number, Actual Carrier, Address, and Actual Scan Time.The Invalid Scan Report can be viewed/printed the following day afterMSP performance information has been uploaded into DOIS and can begenerated for a single service date. It is accessible from the StreetManagement tab on the Supervisor Workbench.

For the Carrier/Route Assignment Report menu, in one embodiment theService Date field can be removed. Since the Revised Carrier/RouteAssignment Report is a planning report, it will only be generated forthe current service date. Further, in this embodiment the Report Typeframe can be removed. The user can only select a carrier since thereport focuses specifically on the selected carrier's line of travel forthe current service date. In addition, the Revised Carrier/RouteAssignment Report can be configured to focus specifically on a carrier'sline of travel. MSP functionality has also been added to the report. TheCarrier/Route Report can be generated for any carrier with a street orstreet assistance assignment. This report can be accessible from theDaily Workload Management tab on the Supervisor Workbench.

In one embodiment, the Unit Feedback Report can display MSPfunctionality. The MSP Overview Report can be added to the Timeliness ofReports sub-section of Quality Practices. Users can view the First Use,Last Use, and Times Used statistics for this report. In addition, MSPManagement data can be added to the Effectiveness section. The followingvalues can be displayed under this sub-category: Possible Office Scans,Missed Office Scans, Office Scan Percentage, Possible Street Scans,Missed Street Scans, Invalid Street Scans, Street Scan Percentage, andOn-Time Street Scan Percentage. This report can be accessible from thePerformance Reports tab on the Supervisor Workbench.

Additionally, the Non-Delivery Point Maintenance window can beaccessible from the Route Inspections and Adjustments Workbench and theRoute and Unit Maintenance tab on the Supervisor Workbench. An AddNon-Delivery Point window can be accessible from the Route Re-sequencingwindow in the Route portion of DOIS. Further, an Edit Non-Delivery Pointwindow can also be accessible from the Non-Delivery Point Maintenancewindow and the Route Re-sequencing window. Also, a 3999 DataCapture/Summary window can be accessible from the 3999 Data CaptureRecord Selection window on the Route Inspections and AdjustmentsWorkbench and the Route and Unit Maintenance tab on the SupervisorWorkbench. And, a Route Re-Sequencing window providing access to the MSPBase Information Maintenance window can be accessible from the CreateAdjustment Scenarios window on the Route Inspections and AdjustmentsWorkbench.

Other embodiments of the invention will be apparent to those skilled inthe art from consideration of the specification and practice of theinvention disclosed herein. For example, the entire system could be madeavailable to users online. It is intended that the specification andexamples be exemplary only, with a true scope and spirit of theinvention being indicated by the following claims.

1. A method for managing delivery of articles to locations along routesover a plurality of days comprising: developing a first database thatidentifies routes for delivery of said articles; developing a seconddatabase that identifies regularly scheduled carriers; assigningcarriers to said routes in response to said data from said first andsecond databases; providing display screens selectively showing saidcarriers assigned to said routes and showing the number of hoursprojected for those carriers to complete those routes over saidplurality of days; developing a third database that identifies saidassignments and projected hours; developing a fourth database thatidentifies budgeted work hours for said carriers; and providing displayscreens selectively showing data from said third and fourth databases ina form that permits comparison of the hours projected and hours budgetedfor the delivery of said articles along said routes over said pluralityof days.
 2. The method of claim 1, wherein the plurality of dayscomprises a week.
 3. The method of claim 1, wherein the plurality ofdays comprise more than a week.
 4. The method of claim 1, furtherincluding the step of determining which carrier has requested to workovertime.
 5. The method of claim 4, further providing a warning prior toassigning a carrier overtime if the carrier has reached a thresholdamount of overtime.
 6. The method of claim 5, wherein the thresholdamount comprises more than a predetermined frequency of days workedovertime for a select time interval.
 7. The method of claim 1, furtherincluding the step of adjusting a carrier's route.
 8. The method ofclaim 1, further including the step of assigning another carrier toassist on a delivery route.
 9. The method of claim 1, further includingthe step of recording which carrier has declined to work overtime. 10.The method of claim 1, further including the step of preparing a budgetbased on selective data from the first, second, third, and fourthdatabases.
 11. A system for managing delivery of articles to locationsalong routes over a plurality of days comprising: a first database thatidentifies routes for delivery of said articles; a second database thatidentifies regularly scheduled carriers; a component for assigningcarriers to said routes in response to said data from said first andsecond databases; a display screen for selectively showing said carriersassigned to said routes and showing the number of hours projected forthose carriers to complete those routes over said plurality of days; athird database that identifies said assignments and projected hours; afourth database that identifies budgeted work hours for said carriers;and a display screen for selectively showing data from said third andfourth databases in a form that permits comparison of the hoursprojected and hours budgeted for the delivery of said articles alongsaid routes over said plurality of days.
 12. The system of claim 11,wherein the plurality of days comprises a week.
 13. The system of claim11, wherein the plurality of days comprise more than a week.
 14. Thesystem of claim 11, further including a component for determining whichcarrier has requested to work overtime.
 15. The system of claim 14,wherein the system provides a warning prior to assigning a carrierovertime if the carrier has reached a threshold amount of overtime. 16.The system of claim 15, wherein the threshold amount comprises more thana predetermined frequency of days worked overtime for a select timeinterval.
 17. The system of claim 11, further including a component foradjusting a carrier's route.
 18. The system of claim 11, furtherincluding a component for assigning another carrier to assist on adelivery route.
 19. The system of claim 11, wherein the system isconfigured to record which carrier has declined to work overtime. 20.The system of claim 11, further including a component for preparing abudget based on selective data from the first, second, third, and fourthdatabases.